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の忖度で「マネジメントも僕の修正も完璧、イエーイ、パチパチパチ」と小綺麗に改竄された履歴からでは、何も改善出来ない。

825(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y) [sage] 2023/08/20(日) 08:35:35.57 ID:Vn08TQPe0(3/7) AAS
>>822
そりゃ探せばあるだろうが、ここでの議論通り、gitでは「清書しろ」が多数派だろ。
この遠因になってるのは、適切なgrepが無く、クソ汚いcommit履歴が丸見えになってしまうからだ。
それを「歴史か物語か」という「選択」だと誤魔化すのは機能が足りてないから。

例えばcommitにレベルが付加されてて、799branchのコミットレベルは2、masterのコミットレベルは0としておけば、
master上に799のドタバタ奮闘記commitsがFFマージで連なっても、
レベル0だけを表示すればマージ人員用の小綺麗な履歴、
レベル2も表示すればパッチ作成者の実際の奮闘含めての履歴、が得られる。
改竄する必要もなく、情報も落としておらず、誰にも余計な手間がかからない。
gitにはこういう「こうすりゃ良かっただけだろ」的な仕様が全部抜け落ちてて、
全部マージ人員(=Linus)側に都合がいいだけの仕様になってる。
この違和感をお前らが感じないのは、お前らがコードなんて書いてないからだと思うぜ。

ついでに言うと「清書」されたcommitsが欲しければ、それはレベル1として「別パス」を「後付で」生成、
つまりスタート/エンドポイントが799branchと同じ、ただし途中の進行が違う別パスを「後付で」追加出来れば、
レベル0は淡々とした履歴、レベル1で修正内容が「清書」された履歴、レベル2で実際の履歴、が得られてみんな幸せだろ。
マネージャが無能でAは止めると確定してからレベル1の「清書」を作成だ。これが最大効率だ。
高い確率で必要ない「清書」を毎回ご丁寧にやる意味はない。

853(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y) [sage] 2023/08/23(水) 07:41:56.03 ID:01C6a53i0(1) AAS
個人ならどうぞ御勝手にだが、会社なら収益(＝効率)で使う使わないが決まる。
ツール(git)で補完される能力が既に足りてれば効果がなく、いわゆる日本の会社なら大体これに該当する。
だから「gitにしてから心も体も収益も絶好調でアットホームな職場です(目線)」なんて事にはならない。

845(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y) [sage] 2023/08/20(日) 22:08:39.08 ID:Vn08TQPe0(7/7) AAS
>>842
ただ集中型が求めるマネジメントは並の会社なら十分満足してる程度だけどな。
難易度/分量の見積もりが取れないようでは、査定/人員確保/納期見積もりも出来ないし。
gitはそれすら必要ないという意味では上だが、普通に会社として成立してる限り既に間に合ってる。
むしろ見積もりを取れない初心者(＝プログラミング経験3000時間以下)に有効なんだろうよ。

後は、バザールは個々の人員の能力を要求するので、特に新卒一括採用な日本の会社にはフィットしない。
gitはバザールでこそ輝く。逆に言えば、バザールでなければ他vcsと大して変わらない。

例えば DB/Go/HTML/CSS/JS を使ってブラウザゲームを提供してる部署があったとして、
部署内バザール、つまり、ユーザーからのアップデート要求事項を一覧として張り出し、
誰がどれを実装してもよい、どの階層/どの言語をどういじってもよい、なんて事が出来てる会社はほぼ無いだろ。
全員が中途採用だと成立するかもしれんが、
新卒一括採用をしてる現実的には、
新人には比較的簡単な仕事(＝割のよい仕事)を振って慣らす必要があり、
結果的にベテランに比較的難しい仕事（＝割りの悪い仕事)を振る、
新人護送船団方式開発をするしかない。
となると誰かしら仕事を差配する奴が必要で、そいつがいる限りgitは不要でsvnでも何ら問題なくなる。

構造的には、新卒一括採用前提の日本の会社の各部署には必ず仕事の難易度を判定出来る奴が存在しており、
そいつがいる限り集中型のvcsが完全に機能するので、
gitにしたところで特段に恩恵があるわけではない為、積極的には移行しないという事。