[過去ﾛｸﾞ] Git 19 (1002ﾚｽ)

Git 19 http://mevius.5ch.net/test/read.cgi/tech/1667720427/

上下前次1-新
通常表示 512ﾊﾞｲﾄ分割 ﾚｽ栞
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん

---

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ

---

820: デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y) [sage] 2023/08/20(日) 00:58:08.93 ID:Vn08TQPe0 >>813 では何故改竄された綺麗な履歴を欲しがる？ 俺なら799の場合は 上側のドタバタ履歴全部＋最終コミットのコメントを「AとCの機能追加、およびコード整理」 として実際の履歴で登録し、 masterにFFマージでこのドタバタ履歴が全部繋がってもgrepですっ飛ばせるのだから問題ないよね、 としたいが、実際はこれが出来ないから手動で改竄した綺麗な履歴を欲しがっているのではないのか？ http://mevius.5ch.net/test/read.cgi/tech/1667720427/820

824: デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y) [sage] 2023/08/20(日) 08:34:32.23 ID:Vn08TQPe0 >>821 簡単に対応する必要がないんだよ。 Cがmust、Aがオプションなら、最初から担当者にその旨伝え、分離した形で実装させなければならない。 それをせずに後付でAはやっぱり止めろ、と言うのはマネジメントの失敗であり、 担当者は適切な再実装時間を要求していい。 実際、799の場合なら、上側の実際の変更に6時間、 これを「清書」して下側の履歴に改竄するのに2時間といったところだろう。 「清書」しなくて良ければ次の仕事に取りかかれるので、この時点で効率が75%に落ちてしまっている。 25%も無能マネージャの尻ぬぐい保険に費やすのは馬鹿げている。 そして実際、殆どの場合は「やっぱAやめろ」なんて事にはならないし、 言われてから対応しても本修正(6時間)と同等の時間で対応出来るものだから、言われてからでいい。 事実としてAとC纏めて修正してしまったのだから、そのまま報告しとけ、でしかない。 >>823 「情報を落とすな」というセオリー通りだ。 > 開発プロセスの資産(812) が開発プロセスの改善を目指すものなら、なおのことだ。 マネジメントが無能で修正指示不足(例:上記の「分離」指示不足)による手戻りが多かった場合、 それがそのまま見える形で記録されてないと意味無い。 799の忖度で「マネジメントも僕の修正も完璧、イエーイ、パチパチパチ」と小綺麗に改竄された履歴からでは、何も改善出来ない。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/824

825: デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y) [sage] 2023/08/20(日) 08:35:35.57 ID:Vn08TQPe0 >>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の「清書」を作成だ。これが最大効率だ。 高い確率で必要ない「清書」を毎回ご丁寧にやる意味はない。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/825

831: デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y) [sage] 2023/08/20(日) 10:17:14.38 ID:Vn08TQPe0 >>826 だからgitはマージ専用機であり、gitを使えばマージの効率は上がる。 ただそれは多数側のコード書いてる担当者に負担を押しつけた結果だから、アプリケーション全体の開発効率は下がる。 ってのがgitの問題点だろうよ。 (しかもこれは意図的な仕様だ) http://mevius.5ch.net/test/read.cgi/tech/1667720427/831

838: デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y) [sage] 2023/08/20(日) 13:18:50.21 ID:Vn08TQPe0 >>834 その程度のコストは普通の会社なら当たり前のようにかけてる。というか、そうじゃないと成立しない。 当たり前だが担当に振る前に、振る側は、担当の実力と、修正箇所の概略は把握してる。 だから「Aの担当モジュールだからAにやらせる」とか、 「この修正は難しいからBにやらせる」とかの判断が出来る。 この過程で、ファイル○○はAとBが変更する可能性がある、というのも分かるから、 Aに先にやらせてその後にB、程度の交通整理でマージの回避も出来る。 対してLinuxの場合は本質的にこれが出来ない。 パッチを送ってくる奴等の実力もさっぱり予測出来ないし、指示も強制も出来ない。 これは従来の伽藍開発ではあり得なかった状況なので、従来のvcsでは全く対応出来ず、gitを作った。 つまりLinusは「無重力でも書けるボールペン」として「無マネジメントでもマージ出来る」gitを作り、 従来の会社は、「Aに先にやらせる」程度のマネジメントで「一方ロシアは鉛筆を使った」が成立してる。 (つまり、集中型のvcsはある程度マネジメントがある前提でしか成立しない) http://mevius.5ch.net/test/read.cgi/tech/1667720427/838

839: デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y) [sage] 2023/08/20(日) 13:19:06.52 ID:Vn08TQPe0 その程度のマネジメントしかしてない奴に高い給料は無意味、 首にしてその分担当を増やせ、というのもありだし、実際に成立する会社があれば面白いとは思う。 つまり、例えばゲーム会社で社内バザールを行い、 ・社内のどのゲーム開発に参画してもよい ・どの仕事をやってもよい 　つまり、キャラデザ、3Dモデル、背景、シナリオ、ゲームエンジン、コーディング、テスト、営業等、 　募集している職にはどれでも応募出来る ・完全出来高制、採用されなければ給料無し(コード書いてもrejectされれば無報酬) という、よくある異世界アニメのギルド依頼をこなすノリで仕事を選ぶ場合は、 集中型のvcsでは役に立たない。 だけど実際、こんな会社はないだろ。社内公募って言ってもねえ、だし。 実際、社内バザールを成立させるにはかなりのマネジメント能力が必要で、現実的に出来る会社がないからだよ。 人気ゲームばかりに人員が集中したり、絵を描きたい奴がキャラデザに集中しても、 強制的に配属することは出来ず、報酬を上げて釣るしかないのだが、この『適正な』報酬を見切れる奴がいない。 しかも有能な奴ほど「割のいい仕事」に対する目利きが効くので、いろんな意味でろくな事にならない。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/839

845: デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y) [sage] 2023/08/20(日) 22:08:39.08 ID:Vn08TQPe0 >>842 ただ集中型が求めるマネジメントは並の会社なら十分満足してる程度だけどな。 難易度/分量の見積もりが取れないようでは、査定/人員確保/納期見積もりも出来ないし。 gitはそれすら必要ないという意味では上だが、普通に会社として成立してる限り既に間に合ってる。 むしろ見積もりを取れない初心者(＝プログラミング経験3000時間以下)に有効なんだろうよ。 後は、バザールは個々の人員の能力を要求するので、特に新卒一括採用な日本の会社にはフィットしない。 gitはバザールでこそ輝く。逆に言えば、バザールでなければ他vcsと大して変わらない。 例えば DB/Go/HTML/CSS/JS を使ってブラウザゲームを提供してる部署があったとして、 部署内バザール、つまり、ユーザーからのアップデート要求事項を一覧として張り出し、 誰がどれを実装してもよい、どの階層/どの言語をどういじってもよい、なんて事が出来てる会社はほぼ無いだろ。 全員が中途採用だと成立するかもしれんが、 新卒一括採用をしてる現実的には、 新人には比較的簡単な仕事(＝割のよい仕事)を振って慣らす必要があり、 結果的にベテランに比較的難しい仕事（＝割りの悪い仕事)を振る、 新人護送船団方式開発をするしかない。 となると誰かしら仕事を差配する奴が必要で、そいつがいる限りgitは不要でsvnでも何ら問題なくなる。 構造的には、新卒一括採用前提の日本の会社の各部署には必ず仕事の難易度を判定出来る奴が存在しており、 そいつがいる限り集中型のvcsが完全に機能するので、 gitにしたところで特段に恩恵があるわけではない為、積極的には移行しないという事。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/845

---

ﾒﾓ帳

(0/65535文字)

---

上下前次1-新書関写板覧索設栞歴

---

ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ

---

Google検索

Wikipedia

---

ぬこの手 ぬこTOP 0.040s