820(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y) [sage] 2023/08/20(日) 00:58:08.93 ID:Vn08TQPe0(1/7) AAS
>>813
では何故改竄された綺麗な履歴を欲しがる？
俺なら799の場合は

上側のドタバタ履歴全部＋最終コミットのコメントを「AとCの機能追加、およびコード整理」

として実際の履歴で登録し、
masterにFFマージでこのドタバタ履歴が全部繋がってもgrepですっ飛ばせるのだから問題ないよね、
としたいが、実際はこれが出来ないから手動で改竄した綺麗な履歴を欲しがっているのではないのか？

824(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y) [sage] 2023/08/20(日) 08:34:32.23 ID:Vn08TQPe0(2/7) AAS
>>821
簡単に対応する必要がないんだよ。

Cがmust、Aがオプションなら、最初から担当者にその旨伝え、分離した形で実装させなければならない。
それをせずに後付でAはやっぱり止めろ、と言うのはマネジメントの失敗であり、
担当者は適切な再実装時間を要求していい。

実際、799の場合なら、上側の実際の変更に6時間、
これを「清書」して下側の履歴に改竄するのに2時間といったところだろう。
「清書」しなくて良ければ次の仕事に取りかかれるので、この時点で効率が75%に落ちてしまっている。
25%も無能マネージャの尻ぬぐい保険に費やすのは馬鹿げている。
そして実際、殆どの場合は「やっぱAやめろ」なんて事にはならないし、
言われてから対応しても本修正(6時間)と同等の時間で対応出来るものだから、言われてからでいい。
事実としてAとC纏めて修正してしまったのだから、そのまま報告しとけ、でしかない。

>>823
「情報を落とすな」というセオリー通りだ。
> 開発プロセスの資産(812)
が開発プロセスの改善を目指すものなら、なおのことだ。
マネジメントが無能で修正指示不足(例:上記の「分離」指示不足)による手戻りが多かった場合、
それがそのまま見える形で記録されてないと意味無い。
799の忖度で「マネジメントも僕の修正も完璧、イエーイ、パチパチパチ」と小綺麗に改竄された履歴からでは、何も改善出来ない。

829(1): デフォルトの名無しさん (ﾜｯﾁｮｲ db8c-RKQT) [sage] 2023/08/20(日) 09:56:03.93 ID:DNMNb0+B0(1/2) AAS
現実を見ていない妄想まみれのレスは置いといて、gitで清書したコミットだけをpushする方法ってあるのかしらん？

ずいぶん前の話なので今は挙動違うかもしれんが、書き散らかした十数のコミットがあってマージでひとつにまとめたとき、まとめた方のコミットだけpushしようとしても十数のコミットもおまけにpushされる。
このおまけのpushを避ける方法てあるのかしらん？

831(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y) [sage] 2023/08/20(日) 10:17:14.38 ID:Vn08TQPe0(4/7) AAS
>>826
だからgitはマージ専用機であり、gitを使えばマージの効率は上がる。
ただそれは多数側のコード書いてる担当者に負担を押しつけた結果だから、アプリケーション全体の開発効率は下がる。

ってのがgitの問題点だろうよ。
(しかもこれは意図的な仕様だ)