[過去ﾛｸﾞ] Git 19 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
743(2): デフォルトの名無しさん (ﾜｯﾁｮｲ ab7b-SLZP) [sage] 2023/08/17(木) 08:31:55.84 ID:zl6mWfwu0(1/4) AAS
>>742
gitを使えば全てが解決して幸せになれると信じるgit統一教信者乙
そりゃお前がsvnのブランチモデルを活用出来ないだけ
git使うだけでリリースが1ヶ月早められるのなら、みんなgit使ってるよ
連中にとってメリットがないからgitを使わないだけという事実をきちんと受け止めた方がいい
そもそも俺はブランチで効率が上がるのはマネジメント不足なだけで本末転倒だとも思うが
(巻き戻し《≒ブランチの破棄》が行われない限りブランチで効率が上がることはないと思ってる
逆に言えばマネジメントがまともに出来ないレベルの連中でもそこそこの開発効率を得られる点ではブランチは有効だが、
会社の場合は既に有能か無能か分かってる連中に仕事を配分するから、そこまで酷くなることはない)
伝わらないかもしれないが、「最終的に『必ず』マージすると分かっている作業なら、
最初からマージした状態で作業を進めていった方が理論的な効率は高い」ということ
つまり、形式としてはsvnの方がgitより理論効率は高いことになる
(実際に出来るかどうかはまた別だが)
多分な、(オープンソース等)ある程度rejectする前提ならgitのように気軽にブランチ丸ごと捨てられる構造が便利だが、
(プロプライエタリ等)最終的に全員のコードをマージする前提で仕事配分してたら、svnでも、ブランチ無くても、大して問題ないって事だと思う
748: デフォルトの名無しさん (ﾜｯﾁｮｲ ab7b-SLZP) [sage] 2023/08/17(木) 12:11:03.75 ID:zl6mWfwu0(2/4) AAS
>>745
> 同じファイルを触ってたらわけわかんなくなるな。
その通りだが、それがどれだけあるかという話なのと、アナログに回避出来るという事。
理解してくれてると思うが、俺が言ってるのは、最終的にFast-Forwardマージしていくのなら、
最初からそのラインを辿るように変更していくのが最大効率だということ。
そしてこれは難しいことでもない。会社で仕事を差配する側なら当然全員出来る。
(逆に言えば、ブランチはまともなマネジメントが出来ないレベルでも何とかなるようにした。
だからある意味初心者ほどブランチの恩恵にあやかれる。多分git信者がブランチにこだわるのはこれ)
同一ファイルを同時に変更するにはブランチが必要だが、これは単純に、
・同時には変更せず、シリアルに変更する。
だってgitでマージしたら結果的に見た目はそうなるのだし、絶対に「同時に」変更する必要があるわけではない。
・そもそも「仕事」で配分してる会社ってあるのか？
Javaのように1クラス1ファイルのように小分けしてて「担当モジュール」制度なら自動的にシリアル化する。
・「仕事」＝「仕様変更/追加」単位で仕事を配分し、全員がどのファイルをどう変更してもいい、最適な箇所を自由に変更しろ
というのは理想的ではあるが、実際は出来ないと思う。
よく知りもしないファイル/モジュールを変更するとバグる(または、潜在バグを埋め込む)ものだから。
担当モジュール制は、実際の所、より非力なチームでも通用する方法であって、
(プロプライエタリまたは少人数等で)実力をお互いに把握出来てる状態ならこれが完全に機能する。(からほぼ全社このシステムのはず)
だからsvnでもブランチ無くても関係ないんだと思うぜ。
(まあgitでも問題ないが、現時点で問題なく機能してるsvnから移行する理由がない)
gitはこの辺linuxに全振りだから、linuxには最適だが、それ以外には大してメリットもない。
ちなみにsvnのブランチなら、他人の作業状態もそれなりに見える。だから遅れてる部分も丸見えではある。
gitの場合は完成品を納品するシステムだから、遅れてる奴が黙ってたら全く検知出来ない。
勿論この辺はgitではなく上位戦略で回避すべき案件ではあるが、実際に問題になることもあるとは思う。
753: デフォルトの名無しさん (ﾜｯﾁｮｲ ab7b-SLZP) [sage] 2023/08/17(木) 15:55:13.44 ID:zl6mWfwu0(3/4) AAS
>>750
つまり「ひとり開発」ではその方法が最大効率だと自明なわけだ
そして「効率」だけを問題にするなら、実は多人数でも同様で、
各自ができるだけ干渉せず、別々にアップデートするだけの、「それぞれが『ひとり開発』状態」に持ち込むのが最大効率だ
これをアナログに目指すなら、綺麗にソースを分離し、各機能を追加/変更する際には別々のファイルに当たるようにすればいい
つまりJava方式も一つのやり方だよ
こういう事前準備を一切せず(出来ず)、デタラメな場合でも、
ブランチだマージだの力業で解決出来るようにした意味はあるが、(＝擬似的に「ひとり開発」状態に持ち込める)
元々無くても困らない(ように事前準備出来る)奴にとっては大した意味はないんだよ
758: デフォルトの名無しさん (ﾜｯﾁｮｲ ab7b-SLZP) [sage] 2023/08/17(木) 21:02:29.62 ID:zl6mWfwu0(4/4) AAS
>>754
> トピックブランチを切って各自がそれぞれ同時並行で作業を進めて最後にマージすること
は
> (＝擬似的に「ひとり開発」状態に持ち込める)
と表現してる。
最大効率（＝余分な作業が一切ない)のは、
・一人で全部シリアルに変更した場合、とこれに準じた
・ブランチを切ってマージした場合に一切競合が無かった場合
だよ。だからブランチはマネジメントが行き届かない場合に効率の低下を防ぐ方策であって、
効率を上げる方策ではないし、十分にマネジメント出来てれば必要ない。
ゲーム開発連中はこれが分かってるからgit(というか君らによるとブランチなのか？)にメリットがないから移行しない。
ただgitのような分散型の場合、本質的にテスト効率が半分なので、
(つまり、ローカルリポジトリの作業でテストした後、マージ後にもう一度同じテストを流す必要がある)
集中型(masterに直接commitしていく場合も同じ)に比べて最終コード(により近い状態)でのテストの積み上がりが遅い。
連中が気にしてるのはこの辺かも。
(まあgitでも誰かしら本体にcommitしたら常にrebaseし直すルールで運用すれば同じにはなるが)
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.049s