ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
http://git-scm.com/
◆関連サイト
Pro Git - Table of Contents
http://git-scm.com/book/ja
Git入門
http://www8.atwiki.jp/git_jp/
◆前スレ
Git 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/
Git 18
http://mevius.5ch.net/test/read.cgi/tech/1650651945/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured
Git 19
レス数が900を超えています。1000を超えると表示できなくなるよ。
1デフォルトの名無しさん (ﾜｯﾁｮｲ 8be4-Cw2/)
2022/11/06(日) 16:40:27.51ID:az1H5JFk0805デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y)
2023/08/19(土) 21:34:40.48ID:2LFpxJcr0 >>802
いや調べてない。以下読んだだけ。
> Mercurialは「履歴は永久的で神聖である」という哲学を持っていて、
> 履歴を操作するコマンドとしては1種類しかありません。
> その一方で、Gitは履歴を操作できる範囲が広いという違いがあります。
> https://tracpath.com/works/development/git-mercurial-subversion/
だから、多分、君らが思ってるほど同じじゃないんだよ。gitは履歴改竄する前提だ。
> どっちも共有リポジトリの改竄は禁止、やったやつは腹を切れ。ローカルはお前にしか影響ないんだから好きにしろ。
これは当たり前で、俺が言ってるのはこれではなく、
「ぐちゃぐちゃ」の履歴を保持する文化があるか、ということ。次レス以降参照
いや調べてない。以下読んだだけ。
> Mercurialは「履歴は永久的で神聖である」という哲学を持っていて、
> 履歴を操作するコマンドとしては1種類しかありません。
> その一方で、Gitは履歴を操作できる範囲が広いという違いがあります。
> https://tracpath.com/works/development/git-mercurial-subversion/
だから、多分、君らが思ってるほど同じじゃないんだよ。gitは履歴改竄する前提だ。
> どっちも共有リポジトリの改竄は禁止、やったやつは腹を切れ。ローカルはお前にしか影響ないんだから好きにしろ。
これは当たり前で、俺が言ってるのはこれではなく、
「ぐちゃぐちゃ」の履歴を保持する文化があるか、ということ。次レス以降参照
806デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y)
2023/08/19(土) 21:36:21.23ID:2LFpxJcr0 >>803
> 個人で残したい履歴と、共有で残したい履歴は違う
> 自分の手元にだけ残っていれば良い
これらはその通りだが、gitにはこれを残す方法が用意されてないだろ。(まあsvn等も同様だとも思うが)
お前は一々別に残せと言うのか？
799通りやってたら既にそれがgitに記録されてるのに？(1回目)
そして共有用に履歴を改竄して、(2回目)
またどこか別にオレオレ用履歴を記録し直すなりしろと？(3回目)
三度手間だろ。
お前らの言う「グチャグチャな」履歴(1回目)を提出すれば(2回目)(3回目)はやらなくて済む作業だよ。
そしてそもそも履歴の哲学が間違ってる。
gitは「歴史か物語か」と嘯いてるが、これは90年代のPCが非力なときの思想であって、
履歴は「全部記録した上で表示時に間引く」と結論は出てて、他も全部そうなってるだろ。
(テキストで言えば>>logしてgrepする)
後になって確認するときにならないと、何が必要だったか分からないものだからだよ。
綺麗に改竄された履歴があったとして、仮に修正漏れがあったとき、
何故修正が漏れたのか、どこで対応し損ねたか、反省も出来ないだろ。
タイポの記録なんて馬鹿げてると思うのなら、タイポしないように注意しろという話であって、
タイポ記録まで含めて記録されてれば、
後から「ああ俺はあのときはこんなにタイポしてたのか、ずいぶんマシになったな」というのも分かるだろ。
小綺麗な記録だけ残ってても大して役に立たない。
記録は「できるだけ情報を削らない」のが大原則だ。
gitはこの辺が根本的に間違ってる。思想が古すぎる。
「歴史か物語か」は、適切にgrepする機構が足りてないのを誤魔化してるだけ。
それで騙されてるお前らはお花畑過ぎる。
> 個人で残したい履歴と、共有で残したい履歴は違う
> 自分の手元にだけ残っていれば良い
これらはその通りだが、gitにはこれを残す方法が用意されてないだろ。(まあsvn等も同様だとも思うが)
お前は一々別に残せと言うのか？
799通りやってたら既にそれがgitに記録されてるのに？(1回目)
そして共有用に履歴を改竄して、(2回目)
またどこか別にオレオレ用履歴を記録し直すなりしろと？(3回目)
三度手間だろ。
お前らの言う「グチャグチャな」履歴(1回目)を提出すれば(2回目)(3回目)はやらなくて済む作業だよ。
そしてそもそも履歴の哲学が間違ってる。
gitは「歴史か物語か」と嘯いてるが、これは90年代のPCが非力なときの思想であって、
履歴は「全部記録した上で表示時に間引く」と結論は出てて、他も全部そうなってるだろ。
(テキストで言えば>>logしてgrepする)
後になって確認するときにならないと、何が必要だったか分からないものだからだよ。
綺麗に改竄された履歴があったとして、仮に修正漏れがあったとき、
何故修正が漏れたのか、どこで対応し損ねたか、反省も出来ないだろ。
タイポの記録なんて馬鹿げてると思うのなら、タイポしないように注意しろという話であって、
タイポ記録まで含めて記録されてれば、
後から「ああ俺はあのときはこんなにタイポしてたのか、ずいぶんマシになったな」というのも分かるだろ。
小綺麗な記録だけ残ってても大して役に立たない。
記録は「できるだけ情報を削らない」のが大原則だ。
gitはこの辺が根本的に間違ってる。思想が古すぎる。
「歴史か物語か」は、適切にgrepする機構が足りてないのを誤魔化してるだけ。
それで騙されてるお前らはお花畑過ぎる。
807デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y)
2023/08/19(土) 21:38:13.61ID:2LFpxJcr0 >>804
それが技術的に出来るのはみんな知ってるよ。
問題は上述の通り、それをやったときに適切にgrepする機構がないから、
最初からgrepした結果になるように履歴を改竄した上でpushしろ、という文化な事。
マージするLinusの都合だけで作ってある。
だからコードを書く側の俺はgitには相当違和感があるし、
805内URLの人もそうだからMercurialとは違うと書いてるのだと思う。
そしてお前らにこの方面の感度が皆無なのは、お前らがコードを書いてないからだとも思う。
まあこれはいい。それで、
> まだ作業中で整理していないブランチもメインリポジトリで共有する
で運用するとして、その先はどうするんだ？
整理したらブランチ消すのか？なら手間が増えてるだけだろ。
svnのブランチ、「ディレクトリがブランチになります！！！」と言い切るのはどうなのよ？とも思うが、
実際、svnなら中途半端なコードを各ブランチに上げられても他の人は全く手間は増えないよ。
のろま君が勝手にコピーしてろで終わりだ。
gitの場合は、のろま君をフォローする為に中央リポジトリが毎日更新されてた場合、
(大した手間ではないが)pushする前にまず中央リポジトリと同期しなければならなくなり、
のろま君の為に全員に手間が増えてる。
これは、分散型のgitで集中管理を行おうとしたから発生したオーバーヘッドであり、
集中型のsvnだったら発生しなかった手間だ。
だから当たり前だが、集中型の開発管理を行うのなら集中型のリポジトリの方が適切だということ。
そして大半のプロプライエタリは集中型の開発なので、ゲーム会社が積極的にgitに移行する理由がない。
(というか連中はここら辺のgitの問題を分かってるから移行してないと思うんだよ。
お前らみたいにgitを理解出来ないから移行出来ないのだ！とかいう、
「上から目線ガー」とかうるさい割には心の中では心底他人を馬鹿にしてるゆとりマインドでは理解不能かもしれんが)
それが技術的に出来るのはみんな知ってるよ。
問題は上述の通り、それをやったときに適切にgrepする機構がないから、
最初からgrepした結果になるように履歴を改竄した上でpushしろ、という文化な事。
マージするLinusの都合だけで作ってある。
だからコードを書く側の俺はgitには相当違和感があるし、
805内URLの人もそうだからMercurialとは違うと書いてるのだと思う。
そしてお前らにこの方面の感度が皆無なのは、お前らがコードを書いてないからだとも思う。
まあこれはいい。それで、
> まだ作業中で整理していないブランチもメインリポジトリで共有する
で運用するとして、その先はどうするんだ？
整理したらブランチ消すのか？なら手間が増えてるだけだろ。
svnのブランチ、「ディレクトリがブランチになります！！！」と言い切るのはどうなのよ？とも思うが、
実際、svnなら中途半端なコードを各ブランチに上げられても他の人は全く手間は増えないよ。
のろま君が勝手にコピーしてろで終わりだ。
gitの場合は、のろま君をフォローする為に中央リポジトリが毎日更新されてた場合、
(大した手間ではないが)pushする前にまず中央リポジトリと同期しなければならなくなり、
のろま君の為に全員に手間が増えてる。
これは、分散型のgitで集中管理を行おうとしたから発生したオーバーヘッドであり、
集中型のsvnだったら発生しなかった手間だ。
だから当たり前だが、集中型の開発管理を行うのなら集中型のリポジトリの方が適切だということ。
そして大半のプロプライエタリは集中型の開発なので、ゲーム会社が積極的にgitに移行する理由がない。
(というか連中はここら辺のgitの問題を分かってるから移行してないと思うんだよ。
お前らみたいにgitを理解出来ないから移行出来ないのだ！とかいう、
「上から目線ガー」とかうるさい割には心の中では心底他人を馬鹿にしてるゆとりマインドでは理解不能かもしれんが)
808デフォルトの名無しさん (ﾜｯﾁｮｲ 2b8f-mdXp)
2023/08/19(土) 21:45:36.49ID:QQmUr01P0 コミットが開発プロセスの資産であることを本質的にわかってないんだろうね
うちのプロジェクトのメンバーにもそういう人がいるんだよね
毎回説明しても理解してくれない…
うちのプロジェクトのメンバーにもそういう人がいるんだよね
毎回説明しても理解してくれない…
809デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y)
2023/08/19(土) 22:22:25.04ID:2LFpxJcr0 >>808
コードが資産で、コミットやgitでの管理は手段だよ。
それは典型的な手段の目的化であり、お前が間違ってる。
ユーザーが求めてるのは、新規機能の実装やバグの修正であって、
綺麗なcommit履歴のgitリポジトリではない。
と毎回説明しても理解してくれない…とそいつも思ってるだろうよ。
コードが資産で、コミットやgitでの管理は手段だよ。
それは典型的な手段の目的化であり、お前が間違ってる。
ユーザーが求めてるのは、新規機能の実装やバグの修正であって、
綺麗なcommit履歴のgitリポジトリではない。
と毎回説明しても理解してくれない…とそいつも思ってるだろうよ。
810デフォルトの名無しさん (ﾜｯﾁｮｲ 2bcf-YAjS)
2023/08/19(土) 22:41:56.92ID:ndraJbkl0 >ユーザーが求めてるのは、新規機能の実装やバグの修正であって、
gitを使ってそれができているならなんの問題もないわけだがあんたはいったいなにを主張したいんだろうか
gitを使ってそれができているならなんの問題もないわけだがあんたはいったいなにを主張したいんだろうか
811デフォルトの名無しさん (ﾜｯﾁｮｲ 2bbb-8Zil)
2023/08/19(土) 22:55:00.77ID:Af/nXbF+0 >>806
>> 個人で残したい履歴と、共有で残したい履歴は違う
>> 自分の手元にだけ残っていれば良い
> これらはその通りだが、gitにはこれを残す方法が用意されてないだろ。
わざわざ消さなければ残っているのにどうして別の方法が必要なんだ？
>履歴は「全部記録した上で表示時に間引く」と結論は出てて、他も全部そうなってるだろ。
お前の脳内結論とか持ってこられても開発効率は上がらないんだよ。複雑なバグの追跡やコードの再利用には綺麗な履歴が必須。
>> 個人で残したい履歴と、共有で残したい履歴は違う
>> 自分の手元にだけ残っていれば良い
> これらはその通りだが、gitにはこれを残す方法が用意されてないだろ。
わざわざ消さなければ残っているのにどうして別の方法が必要なんだ？
>履歴は「全部記録した上で表示時に間引く」と結論は出てて、他も全部そうなってるだろ。
お前の脳内結論とか持ってこられても開発効率は上がらないんだよ。複雑なバグの追跡やコードの再利用には綺麗な履歴が必須。
812デフォルトの名無しさん (ﾜｯﾁｮｲ 2b8f-mdXp)
2023/08/19(土) 22:57:43.95ID:QQmUr01P0813デフォルトの名無しさん (ﾜｯﾁｮｲ abe4-Xr9l)
2023/08/19(土) 23:16:41.01ID:vl4t9mIK0814デフォルトの名無しさん (ﾜｯﾁｮｲ 2bbb-8Zil)
2023/08/19(土) 23:17:28.06ID:Af/nXbF+0 >>807
svn 使ったことないのに、知ってる風を装って語るので嘘杉て笑いが止まらない。
push する前に同期が必要なのが git
commit する前に同期が必要なのが svn
理解できるかな？ 無理だろうな。
svn 使ったことないのに、知ってる風を装って語るので嘘杉て笑いが止まらない。
push する前に同期が必要なのが git
commit する前に同期が必要なのが svn
理解できるかな？ 無理だろうな。
815デフォルトの名無しさん (ﾜｯﾁｮｲ abe4-Xr9l)
2023/08/19(土) 23:19:47.05ID:vl4t9mIK0 >>807
作業中のブランチをレビューするのにメインリポジトリで共有するのはそれが簡単だから
レビューするのに最新の状態との同期とか必用無いし
作業前の状態との比較も簡単にできるし
そのままで問題なさそうなら最終成果物としてマージできるように同期して調整するのも簡単
必要無くなったら消すのも簡単
お前の妄想する手間がかかるから無駄とかこの機能を使わない理由のなんの説明にもなっていない
お前は理解できてないから手間がかかるとか無駄とか妄想を垂れ流す
作業中のブランチをレビューするのにメインリポジトリで共有するのはそれが簡単だから
レビューするのに最新の状態との同期とか必用無いし
作業前の状態との比較も簡単にできるし
そのままで問題なさそうなら最終成果物としてマージできるように同期して調整するのも簡単
必要無くなったら消すのも簡単
お前の妄想する手間がかかるから無駄とかこの機能を使わない理由のなんの説明にもなっていない
お前は理解できてないから手間がかかるとか無駄とか妄想を垂れ流す
816デフォルトの名無しさん (ﾜｯﾁｮｲ abe4-Xr9l)
2023/08/19(土) 23:21:47.54ID:vl4t9mIK0817デフォルトの名無しさん (ﾜｯﾁｮｲ 2bbb-8Zil)
2023/08/19(土) 23:38:08.78ID:Af/nXbF+0 >>816
ごめん。何を言ってるのか分からない。まさか push -f しろと主張してるの？
ごめん。何を言ってるのか分からない。まさか push -f しろと主張してるの？
818デフォルトの名無しさん (ﾜｯﾁｮｲ abe4-Xr9l)
2023/08/19(土) 23:43:08.38ID:vl4t9mIK0819デフォルトの名無しさん (ﾜｯﾁｮｲ 2bbb-8Zil)
2023/08/19(土) 23:51:47.78ID:Af/nXbF+0 >>818
なら単に用語の問題だな
git の push はブランチ単位での同期を要求する。push するブランチの同期が取れてるなら当然それ以上同期コマンドを実行する必要はない。
svn の commit はチェックアウトした範囲全体の同期を要求する。リポジトリ全体をチェックアウトしたなら全体の同期が必要。
まあどっちもとりあえずやってみて、失敗したら同期コマンド打てば良いだけだけどな
なら単に用語の問題だな
git の push はブランチ単位での同期を要求する。push するブランチの同期が取れてるなら当然それ以上同期コマンドを実行する必要はない。
svn の commit はチェックアウトした範囲全体の同期を要求する。リポジトリ全体をチェックアウトしたなら全体の同期が必要。
まあどっちもとりあえずやってみて、失敗したら同期コマンド打てば良いだけだけどな
820デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y)
2023/08/20(日) 00:58:08.93ID:Vn08TQPe0 >>813
では何故改竄された綺麗な履歴を欲しがる？
俺なら799の場合は
上側のドタバタ履歴全部＋最終コミットのコメントを「AとCの機能追加、およびコード整理」
として実際の履歴で登録し、
masterにFFマージでこのドタバタ履歴が全部繋がってもgrepですっ飛ばせるのだから問題ないよね、
としたいが、実際はこれが出来ないから手動で改竄した綺麗な履歴を欲しがっているのではないのか？
では何故改竄された綺麗な履歴を欲しがる？
俺なら799の場合は
上側のドタバタ履歴全部＋最終コミットのコメントを「AとCの機能追加、およびコード整理」
として実際の履歴で登録し、
masterにFFマージでこのドタバタ履歴が全部繋がってもgrepですっ飛ばせるのだから問題ないよね、
としたいが、実際はこれが出来ないから手動で改竄した綺麗な履歴を欲しがっているのではないのか？
821デフォルトの名無しさん (ﾜｯﾁｮｲ 2bbb-8Zil)
2023/08/20(日) 01:06:37.87ID:vNIwX77X0 >>820
じゃあ、ゴミログ残して、お前このあと C は必要だが A は別の機会にってなったときに簡単に対応できるか？
後から他人のゴミログ追いかけて必要な部分と不要な部分切り分ける手間暇馬鹿にならないし、ミスする確率も増える
じゃあ、ゴミログ残して、お前このあと C は必要だが A は別の機会にってなったときに簡単に対応できるか？
後から他人のゴミログ追いかけて必要な部分と不要な部分切り分ける手間暇馬鹿にならないし、ミスする確率も増える
822デフォルトの名無しさん (ﾜｯﾁｮｲ abe4-Xr9l)
2023/08/20(日) 01:49:04.21ID:st7HSyAz0823デフォルトの名無しさん (ﾜｯﾁｮｲ d163-Wp5N)
2023/08/20(日) 04:04:05.06ID:Qj2YxZj80 長文くんの考えは全部捨てずに突っ込んでおけば必要なものは探し出せるはずで
整理整頓なんか不要だし見た目が悪くても気にしないしそれで他の人が困ろうとどうでもいい
というゴミ屋敷理論だからなあ
整理整頓なんか不要だし見た目が悪くても気にしないしそれで他の人が困ろうとどうでもいい
というゴミ屋敷理論だからなあ
824デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y)
2023/08/20(日) 08:34:32.23ID:Vn08TQPe0 >>821
簡単に対応する必要がないんだよ。
Cがmust、Aがオプションなら、最初から担当者にその旨伝え、分離した形で実装させなければならない。
それをせずに後付でAはやっぱり止めろ、と言うのはマネジメントの失敗であり、
担当者は適切な再実装時間を要求していい。
実際、799の場合なら、上側の実際の変更に6時間、
これを「清書」して下側の履歴に改竄するのに2時間といったところだろう。
「清書」しなくて良ければ次の仕事に取りかかれるので、この時点で効率が75%に落ちてしまっている。
25%も無能マネージャの尻ぬぐい保険に費やすのは馬鹿げている。
そして実際、殆どの場合は「やっぱAやめろ」なんて事にはならないし、
言われてから対応しても本修正(6時間)と同等の時間で対応出来るものだから、言われてからでいい。
事実としてAとC纏めて修正してしまったのだから、そのまま報告しとけ、でしかない。
>>823
「情報を落とすな」というセオリー通りだ。
> 開発プロセスの資産(812)
が開発プロセスの改善を目指すものなら、なおのことだ。
マネジメントが無能で修正指示不足(例:上記の「分離」指示不足)による手戻りが多かった場合、
それがそのまま見える形で記録されてないと意味無い。
799の忖度で「マネジメントも僕の修正も完璧、イエーイ、パチパチパチ」と小綺麗に改竄された履歴からでは、何も改善出来ない。
簡単に対応する必要がないんだよ。
Cがmust、Aがオプションなら、最初から担当者にその旨伝え、分離した形で実装させなければならない。
それをせずに後付でAはやっぱり止めろ、と言うのはマネジメントの失敗であり、
担当者は適切な再実装時間を要求していい。
実際、799の場合なら、上側の実際の変更に6時間、
これを「清書」して下側の履歴に改竄するのに2時間といったところだろう。
「清書」しなくて良ければ次の仕事に取りかかれるので、この時点で効率が75%に落ちてしまっている。
25%も無能マネージャの尻ぬぐい保険に費やすのは馬鹿げている。
そして実際、殆どの場合は「やっぱAやめろ」なんて事にはならないし、
言われてから対応しても本修正(6時間)と同等の時間で対応出来るものだから、言われてからでいい。
事実としてAとC纏めて修正してしまったのだから、そのまま報告しとけ、でしかない。
>>823
「情報を落とすな」というセオリー通りだ。
> 開発プロセスの資産(812)
が開発プロセスの改善を目指すものなら、なおのことだ。
マネジメントが無能で修正指示不足(例:上記の「分離」指示不足)による手戻りが多かった場合、
それがそのまま見える形で記録されてないと意味無い。
799の忖度で「マネジメントも僕の修正も完璧、イエーイ、パチパチパチ」と小綺麗に改竄された履歴からでは、何も改善出来ない。
825デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y)
2023/08/20(日) 08:35:35.57ID: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の「清書」を作成だ。これが最大効率だ。
高い確率で必要ない「清書」を毎回ご丁寧にやる意味はない。
そりゃ探せばあるだろうが、ここでの議論通り、gitでは「清書しろ」が多数派だろ。
この遠因になってるのは、適切なgrepが無く、クソ汚いcommit履歴が丸見えになってしまうからだ。
それを「歴史か物語か」という「選択」だと誤魔化すのは機能が足りてないから。
例えばcommitにレベルが付加されてて、799branchのコミットレベルは2、masterのコミットレベルは0としておけば、
master上に799のドタバタ奮闘記commitsがFFマージで連なっても、
レベル0だけを表示すればマージ人員用の小綺麗な履歴、
レベル2も表示すればパッチ作成者の実際の奮闘含めての履歴、が得られる。
改竄する必要もなく、情報も落としておらず、誰にも余計な手間がかからない。
gitにはこういう「こうすりゃ良かっただけだろ」的な仕様が全部抜け落ちてて、
全部マージ人員(=Linus)側に都合がいいだけの仕様になってる。
この違和感をお前らが感じないのは、お前らがコードなんて書いてないからだと思うぜ。
ついでに言うと「清書」されたcommitsが欲しければ、それはレベル1として「別パス」を「後付で」生成、
つまりスタート/エンドポイントが799branchと同じ、ただし途中の進行が違う別パスを「後付で」追加出来れば、
レベル0は淡々とした履歴、レベル1で修正内容が「清書」された履歴、レベル2で実際の履歴、が得られてみんな幸せだろ。
マネージャが無能でAは止めると確定してからレベル1の「清書」を作成だ。これが最大効率だ。
高い確率で必要ない「清書」を毎回ご丁寧にやる意味はない。
826デフォルトの名無しさん (ﾃﾃﾝﾃﾝﾃﾝ MM4b-XafZ)
2023/08/20(日) 08:44:51.44ID:fiK4YkusM マージ側に都合がいいというのは正しいかもね。日頃からその視点を持って作業したら。
827デフォルトの名無しさん (ﾜｯﾁｮｲ 2bbb-8Zil)
2023/08/20(日) 08:56:28.01ID:vNIwX77X0828デフォルトの名無しさん (ｱｳｱｳｸｰ MM8d-1fKg)
2023/08/20(日) 08:58:29.28ID:rPtHvv2SM 長文さんは共同開発プロジェクトにgit使ったこと無いんじゃないかな。
むか〜しに共同開発プロジェクトに参画させてもらった記憶だけで長文書いてそう。
こんなごちゃごちゃ口だけやかましい奴はプロジェクト推進の邪魔だから当時退場させられたんだろう多分
むか〜しに共同開発プロジェクトに参画させてもらった記憶だけで長文書いてそう。
こんなごちゃごちゃ口だけやかましい奴はプロジェクト推進の邪魔だから当時退場させられたんだろう多分
829デフォルトの名無しさん (ﾜｯﾁｮｲ db8c-RKQT)
2023/08/20(日) 09:56:03.93ID:DNMNb0+B0 現実を見ていない妄想まみれのレスは置いといて、gitで清書したコミットだけをpushする方法ってあるのかしらん？
ずいぶん前の話なので今は挙動違うかもしれんが、書き散らかした十数のコミットがあってマージでひとつにまとめたとき、まとめた方のコミットだけpushしようとしても十数のコミットもおまけにpushされる。
このおまけのpushを避ける方法てあるのかしらん？
ずいぶん前の話なので今は挙動違うかもしれんが、書き散らかした十数のコミットがあってマージでひとつにまとめたとき、まとめた方のコミットだけpushしようとしても十数のコミットもおまけにpushされる。
このおまけのpushを避ける方法てあるのかしらん？
830デフォルトの名無しさん (ﾜｯﾁｮｲ d19f-q59E)
2023/08/20(日) 10:16:43.69ID:eWjoENHw0 cherry-pick
831デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y)
2023/08/20(日) 10:17:14.38ID:Vn08TQPe0 >>826
だからgitはマージ専用機であり、gitを使えばマージの効率は上がる。
ただそれは多数側のコード書いてる担当者に負担を押しつけた結果だから、アプリケーション全体の開発効率は下がる。
ってのがgitの問題点だろうよ。
(しかもこれは意図的な仕様だ)
だからgitはマージ専用機であり、gitを使えばマージの効率は上がる。
ただそれは多数側のコード書いてる担当者に負担を押しつけた結果だから、アプリケーション全体の開発効率は下がる。
ってのがgitの問題点だろうよ。
(しかもこれは意図的な仕様だ)
832デフォルトの名無しさん (ﾜｯﾁｮｲ 2bbb-8Zil)
2023/08/20(日) 10:35:23.52ID:vNIwX77X0 >>829
多分、すごい古い git を使ってたんじゃないかな？
最近のはデフォルトが変更されていて、現在のブランチだけが push されるので他のものは push されないよ （オプションか設定変更で変えれる）
多分、すごい古い git を使ってたんじゃないかな？
最近のはデフォルトが変更されていて、現在のブランチだけが push されるので他のものは push されないよ （オプションか設定変更で変えれる）
833デフォルトの名無しさん (ﾜｯﾁｮｲ 2bbb-8Zil)
2023/08/20(日) 10:38:38.99ID:vNIwX77X0 >>831
開発効率が下がるのは清書に2時間かけちゃう、お前だけだろ？
開発効率が下がるのは清書に2時間かけちゃう、お前だけだろ？
834デフォルトの名無しさん (ﾜｯﾁｮｲ 2bcf-YAjS)
2023/08/20(日) 10:54:29.71ID:P3ytobrG0 >それをせずに後付でAはやっぱり止めろ、と言うのはマネジメントの失敗であり、
前にもうまくマネジメントすればブランチは不要てなことを書いていたと思うが
それをやるのにかかるコストのことは考えてるんかね。
前にもうまくマネジメントすればブランチは不要てなことを書いていたと思うが
それをやるのにかかるコストのことは考えてるんかね。
835デフォルトの名無しさん (ﾃﾃﾝﾃﾝﾃﾝ MM4b-XafZ)
2023/08/20(日) 11:07:43.43ID:fiK4YkusM 完璧な計画が作れないのはバケツであなたが体験した通りですよ
836デフォルトの名無しさん (ﾌﾞｰｲﾓ MM4b-8Zil)
2023/08/20(日) 12:15:53.56ID:lyAuLRyDM 他人が10秒でやる仕事に2時間かけるのは無能
無能を棚に上げて、マネージメントのせいにして仕事拒否するとか、馬鹿を通り越して害悪
無能を棚に上げて、マネージメントのせいにして仕事拒否するとか、馬鹿を通り越して害悪
837デフォルトの名無しさん (ﾜｯﾁｮｲ db8c-RKQT)
2023/08/20(日) 12:27:33.60ID:DNMNb0+B0838デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y)
2023/08/20(日) 13:18:50.21ID:Vn08TQPe0 >>834
その程度のコストは普通の会社なら当たり前のようにかけてる。というか、そうじゃないと成立しない。
当たり前だが担当に振る前に、振る側は、担当の実力と、修正箇所の概略は把握してる。
だから「Aの担当モジュールだからAにやらせる」とか、
「この修正は難しいからBにやらせる」とかの判断が出来る。
この過程で、ファイル○○はAとBが変更する可能性がある、というのも分かるから、
Aに先にやらせてその後にB、程度の交通整理でマージの回避も出来る。
対してLinuxの場合は本質的にこれが出来ない。
パッチを送ってくる奴等の実力もさっぱり予測出来ないし、指示も強制も出来ない。
これは従来の伽藍開発ではあり得なかった状況なので、従来のvcsでは全く対応出来ず、gitを作った。
つまりLinusは「無重力でも書けるボールペン」として「無マネジメントでもマージ出来る」gitを作り、
従来の会社は、「Aに先にやらせる」程度のマネジメントで「一方ロシアは鉛筆を使った」が成立してる。
(つまり、集中型のvcsはある程度マネジメントがある前提でしか成立しない)
その程度のコストは普通の会社なら当たり前のようにかけてる。というか、そうじゃないと成立しない。
当たり前だが担当に振る前に、振る側は、担当の実力と、修正箇所の概略は把握してる。
だから「Aの担当モジュールだからAにやらせる」とか、
「この修正は難しいからBにやらせる」とかの判断が出来る。
この過程で、ファイル○○はAとBが変更する可能性がある、というのも分かるから、
Aに先にやらせてその後にB、程度の交通整理でマージの回避も出来る。
対してLinuxの場合は本質的にこれが出来ない。
パッチを送ってくる奴等の実力もさっぱり予測出来ないし、指示も強制も出来ない。
これは従来の伽藍開発ではあり得なかった状況なので、従来のvcsでは全く対応出来ず、gitを作った。
つまりLinusは「無重力でも書けるボールペン」として「無マネジメントでもマージ出来る」gitを作り、
従来の会社は、「Aに先にやらせる」程度のマネジメントで「一方ロシアは鉛筆を使った」が成立してる。
(つまり、集中型のvcsはある程度マネジメントがある前提でしか成立しない)
839デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y)
2023/08/20(日) 13:19:06.52ID:Vn08TQPe0 その程度のマネジメントしかしてない奴に高い給料は無意味、
首にしてその分担当を増やせ、というのもありだし、実際に成立する会社があれば面白いとは思う。
つまり、例えばゲーム会社で社内バザールを行い、
・社内のどのゲーム開発に参画してもよい
・どの仕事をやってもよい
つまり、キャラデザ、3Dモデル、背景、シナリオ、ゲームエンジン、コーディング、テスト、営業等、
募集している職にはどれでも応募出来る
・完全出来高制、採用されなければ給料無し(コード書いてもrejectされれば無報酬)
という、よくある異世界アニメのギルド依頼をこなすノリで仕事を選ぶ場合は、
集中型のvcsでは役に立たない。
だけど実際、こんな会社はないだろ。社内公募って言ってもねえ、だし。
実際、社内バザールを成立させるにはかなりのマネジメント能力が必要で、現実的に出来る会社がないからだよ。
人気ゲームばかりに人員が集中したり、絵を描きたい奴がキャラデザに集中しても、
強制的に配属することは出来ず、報酬を上げて釣るしかないのだが、この『適正な』報酬を見切れる奴がいない。
しかも有能な奴ほど「割のいい仕事」に対する目利きが効くので、いろんな意味でろくな事にならない。
首にしてその分担当を増やせ、というのもありだし、実際に成立する会社があれば面白いとは思う。
つまり、例えばゲーム会社で社内バザールを行い、
・社内のどのゲーム開発に参画してもよい
・どの仕事をやってもよい
つまり、キャラデザ、3Dモデル、背景、シナリオ、ゲームエンジン、コーディング、テスト、営業等、
募集している職にはどれでも応募出来る
・完全出来高制、採用されなければ給料無し(コード書いてもrejectされれば無報酬)
という、よくある異世界アニメのギルド依頼をこなすノリで仕事を選ぶ場合は、
集中型のvcsでは役に立たない。
だけど実際、こんな会社はないだろ。社内公募って言ってもねえ、だし。
実際、社内バザールを成立させるにはかなりのマネジメント能力が必要で、現実的に出来る会社がないからだよ。
人気ゲームばかりに人員が集中したり、絵を描きたい奴がキャラデザに集中しても、
強制的に配属することは出来ず、報酬を上げて釣るしかないのだが、この『適正な』報酬を見切れる奴がいない。
しかも有能な奴ほど「割のいい仕事」に対する目利きが効くので、いろんな意味でろくな事にならない。
840デフォルトの名無しさん (ﾜｯﾁｮｲ c963-8siF)
2023/08/20(日) 13:59:49.47ID:DfSYz/4c0 バケツくんと長文くんがいるように見えるのは僕だけかい？
841デフォルトの名無しさん (ﾜｯﾁｮｲ 2b8f-mdXp)
2023/08/20(日) 14:17:18.15ID:6n6PkJKk0 バケツくんは、後で別のプログラマが自分のコミットを参照したり再利用することを考えないんだろうな
人に見せることを考えないので、自分が作業したありのままを残すことに執着する
あとrebaseを行って"清書"を行う自信がないんだろう笑
使ったことがないから笑
人に見せることを考えないので、自分が作業したありのままを残すことに執着する
あとrebaseを行って"清書"を行う自信がないんだろう笑
使ったことがないから笑
842デフォルトの名無しさん (ﾜｯﾁｮｲ 2bcf-YAjS)
2023/08/20(日) 14:19:19.55ID:P3ytobrG0 >(つまり、集中型のvcsはある程度マネジメントがある前提でしか成立しない)
まあその通りだな。で、あんたの要求するレベルの「マネジメント」にパワーをかけたくない現場は
ブランチ使って並行作業するだけ。
>ユーザーが求めてるのは、新規機能の実装やバグの修正であって、
そういうことだな。
まあその通りだな。で、あんたの要求するレベルの「マネジメント」にパワーをかけたくない現場は
ブランチ使って並行作業するだけ。
>ユーザーが求めてるのは、新規機能の実装やバグの修正であって、
そういうことだな。
843デフォルトの名無しさん (ﾜｯﾁｮｲ d163-Wp5N)
2023/08/20(日) 15:33:57.12ID:Qj2YxZj80844デフォルトの名無しさん (ﾜｯﾁｮｲ 5b19-0WDc)
2023/08/20(日) 19:24:45.17ID:Mm91CbZY0 github desktopでもsourcetreeでもいいから変更履歴を複数選択してsquashかけたらあっという間に
履歴をまとめられるのも知らんのだろうな。
履歴をまとめられるのも知らんのだろうな。
845デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y)
2023/08/20(日) 22:08:39.08ID:Vn08TQPe0 >>842
ただ集中型が求めるマネジメントは並の会社なら十分満足してる程度だけどな。
難易度/分量の見積もりが取れないようでは、査定/人員確保/納期見積もりも出来ないし。
gitはそれすら必要ないという意味では上だが、普通に会社として成立してる限り既に間に合ってる。
むしろ見積もりを取れない初心者(＝プログラミング経験3000時間以下)に有効なんだろうよ。
後は、バザールは個々の人員の能力を要求するので、特に新卒一括採用な日本の会社にはフィットしない。
gitはバザールでこそ輝く。逆に言えば、バザールでなければ他vcsと大して変わらない。
例えば DB/Go/HTML/CSS/JS を使ってブラウザゲームを提供してる部署があったとして、
部署内バザール、つまり、ユーザーからのアップデート要求事項を一覧として張り出し、
誰がどれを実装してもよい、どの階層/どの言語をどういじってもよい、なんて事が出来てる会社はほぼ無いだろ。
全員が中途採用だと成立するかもしれんが、
新卒一括採用をしてる現実的には、
新人には比較的簡単な仕事(＝割のよい仕事)を振って慣らす必要があり、
結果的にベテランに比較的難しい仕事（＝割りの悪い仕事)を振る、
新人護送船団方式開発をするしかない。
となると誰かしら仕事を差配する奴が必要で、そいつがいる限りgitは不要でsvnでも何ら問題なくなる。
構造的には、新卒一括採用前提の日本の会社の各部署には必ず仕事の難易度を判定出来る奴が存在しており、
そいつがいる限り集中型のvcsが完全に機能するので、
gitにしたところで特段に恩恵があるわけではない為、積極的には移行しないという事。
ただ集中型が求めるマネジメントは並の会社なら十分満足してる程度だけどな。
難易度/分量の見積もりが取れないようでは、査定/人員確保/納期見積もりも出来ないし。
gitはそれすら必要ないという意味では上だが、普通に会社として成立してる限り既に間に合ってる。
むしろ見積もりを取れない初心者(＝プログラミング経験3000時間以下)に有効なんだろうよ。
後は、バザールは個々の人員の能力を要求するので、特に新卒一括採用な日本の会社にはフィットしない。
gitはバザールでこそ輝く。逆に言えば、バザールでなければ他vcsと大して変わらない。
例えば DB/Go/HTML/CSS/JS を使ってブラウザゲームを提供してる部署があったとして、
部署内バザール、つまり、ユーザーからのアップデート要求事項を一覧として張り出し、
誰がどれを実装してもよい、どの階層/どの言語をどういじってもよい、なんて事が出来てる会社はほぼ無いだろ。
全員が中途採用だと成立するかもしれんが、
新卒一括採用をしてる現実的には、
新人には比較的簡単な仕事(＝割のよい仕事)を振って慣らす必要があり、
結果的にベテランに比較的難しい仕事（＝割りの悪い仕事)を振る、
新人護送船団方式開発をするしかない。
となると誰かしら仕事を差配する奴が必要で、そいつがいる限りgitは不要でsvnでも何ら問題なくなる。
構造的には、新卒一括採用前提の日本の会社の各部署には必ず仕事の難易度を判定出来る奴が存在しており、
そいつがいる限り集中型のvcsが完全に機能するので、
gitにしたところで特段に恩恵があるわけではない為、積極的には移行しないという事。
846デフォルトの名無しさん (ﾜｯﾁｮｲ 2b8f-mdXp)
2023/08/20(日) 22:45:22.16ID:6n6PkJKk0 今のキミより新卒は優秀だから、gitにフィットしないのではとか気にしなくていいよ
847デフォルトの名無しさん (ﾜｯﾁｮｲ 2bcf-YAjS)
2023/08/20(日) 23:02:34.62ID:P3ytobrG0 これだけ長文連騰を続けてもそれに説得されて宗旨替えする人が出てこないことはこれまでの反応から
大体わわかっただろうがそれでもなんで続けているのか不思議に思ってた。
おそらくだが意固地になってgitを使わない自分自身を正当化したいだけなんだろうな。
大体わわかっただろうがそれでもなんで続けているのか不思議に思ってた。
おそらくだが意固地になってgitを使わない自分自身を正当化したいだけなんだろうな。
848デフォルトの名無しさん (ﾜｯﾁｮｲ 2bbb-8Zil)
2023/08/20(日) 23:19:10.98ID:vNIwX77X0 長文君の理論だと Microsoft も Google も Apple も日本の大手各社も git メインで使ってるのでマネージメントできない給料泥棒ばかりだな。
きっとそいつらには理解できなくて優秀な長文君だけ理解できるんだろうな。さぞかし立派な成果出してるんだろうから紹介してくれ。
きっとそいつらには理解できなくて優秀な長文君だけ理解できるんだろうな。さぞかし立派な成果出してるんだろうから紹介してくれ。
849デフォルトの名無しさん (ﾜｯﾁｮｲ 2bc1-XafZ)
2023/08/20(日) 23:38:18.21ID:60s/Im7a0 >>845
新人が編集した内容は初心者だろうがその新人が一番理解しているし、それを積み重ねる結果コードのすべてを把握できるような強いマネージャーはいなくなるので、なるべく誰にでもわかりやすい履歴が求められます。
新人が編集した内容は初心者だろうがその新人が一番理解しているし、それを積み重ねる結果コードのすべてを把握できるような強いマネージャーはいなくなるので、なるべく誰にでもわかりやすい履歴が求められます。
850デフォルトの名無しさん (ﾜｯﾁｮｲ 9363-Wp5N)
2023/08/21(月) 07:46:21.21ID:bL+iSZFD0 >>847
そういうことだな
自分を正当化するために何とか言い返さなければならないということで言い返し続けた結果
gitに乗り換えるところは査定/人員確保/納期見積もりも出来ないし会社として成立していない
と主張することになってしまった
長文くんはどこまで行ってしまうのだろう
そういうことだな
自分を正当化するために何とか言い返さなければならないということで言い返し続けた結果
gitに乗り換えるところは査定/人員確保/納期見積もりも出来ないし会社として成立していない
と主張することになってしまった
長文くんはどこまで行ってしまうのだろう
851デフォルトの名無しさん (ﾜｯﾁｮｲ a197-z8Bp)
2023/08/21(月) 20:59:54.85ID:5gIke5d10 ちゃんとしたマネジメントがあれば分散開発のためのシステムは不要、っていうのは、
井戸に水を汲む係が居れば上水道なんかなくても困らない、っていう意見みたいなもんだぞ。
井戸水を汲む係が居て成立している組織のことを何も否定してないじゃない。
そんな係の担当になったり、係がいることによる不便を感じたりは嫌だから僕らはgitを使うよ、というだけで。
結局は好みで決まるものだと思うよ。
井戸に水を汲む係が居れば上水道なんかなくても困らない、っていう意見みたいなもんだぞ。
井戸水を汲む係が居て成立している組織のことを何も否定してないじゃない。
そんな係の担当になったり、係がいることによる不便を感じたりは嫌だから僕らはgitを使うよ、というだけで。
結局は好みで決まるものだと思うよ。
852デフォルトの名無しさん (ﾜｯﾁｮｲ 5910-U/el)
2023/08/22(火) 08:56:52.59ID:JUa8Ruu50 Git v2.42.0
853デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y)
2023/08/23(水) 07:41:56.03ID:01C6a53i0 個人ならどうぞ御勝手にだが、会社なら収益(＝効率)で使う使わないが決まる。
ツール(git)で補完される能力が既に足りてれば効果がなく、いわゆる日本の会社なら大体これに該当する。
だから「gitにしてから心も体も収益も絶好調でアットホームな職場です(目線)」なんて事にはならない。
ツール(git)で補完される能力が既に足りてれば効果がなく、いわゆる日本の会社なら大体これに該当する。
だから「gitにしてから心も体も収益も絶好調でアットホームな職場です(目線)」なんて事にはならない。
854デフォルトの名無しさん (ﾜｯﾁｮｲ d3e4-4mKs)
2023/08/23(水) 07:50:50.23ID:UQQCU4pK0 これは各パーツの担当者達が好き勝手にブランチ生やして最終的にマージ要員の人がどれマージすりゃいいっすかー？と一人一人に確認しに行く流れかな
Gitってブランチの最終段階だけ取り込んでも道中の変更は反映されないのかな？使い方が悪い？
Gitってブランチの最終段階だけ取り込んでも道中の変更は反映されないのかな？使い方が悪い？
855デフォルトの名無しさん (ﾜｯﾁｮｲ 2b63-Wp5N)
2023/08/23(水) 08:44:47.55ID:/k4AJPVh0856デフォルトの名無しさん (ｱｳｱｳｳｰ Sa45-HTZh)
2023/08/23(水) 09:46:21.13ID:MbpOxYkaa 他所の会社は分からないけど、分散型バージョン管理システムは最高な気がしている。
もっと良いものがあれば教えて欲しい。
もっと良いものがあれば教えて欲しい。
857デフォルトの名無しさん (ﾜｯﾁｮｲ abe4-Xr9l)
2023/08/23(水) 10:32:52.47ID:niebTNUf0 結構有名な話だがGoogleはgitのような分散バージョン管理システムをメインには使っていない
会社の基盤に分散ファイルシステムがあるのでバージョン管理が分散システムである必要が無かった
一つのリポジトリに会社の全コードが格納されている
https://www.school.ctc-g.co.jp/columns/nakai2/nakai220.html
会社の基盤に分散ファイルシステムがあるのでバージョン管理が分散システムである必要が無かった
一つのリポジトリに会社の全コードが格納されている
https://www.school.ctc-g.co.jp/columns/nakai2/nakai220.html
858デフォルトの名無しさん (ﾜｯﾁｮｲ 5b19-0WDc)
2023/08/23(水) 10:33:57.58ID:nEmftCML0 長文君は、
進捗管理するツール作るで→すでにGitHubであるだろ
わ、ワードならどうや？→すでにSharePointであるだろ
と指摘されたので、妬みで周りの邪魔する書き込み繰り返して自我を保ってるだけ
最低限バケツをこれ↓くらいに仕上げるまで書き込み自粛してほしいわ
https://developer.mamezou-tech.com/blogs/2023/03/28/github-projects-new-roadmaps-layout/
はやくしないとGitHub Desktopに実装されるかもしれんぞ？
進捗管理するツール作るで→すでにGitHubであるだろ
わ、ワードならどうや？→すでにSharePointであるだろ
と指摘されたので、妬みで周りの邪魔する書き込み繰り返して自我を保ってるだけ
最低限バケツをこれ↓くらいに仕上げるまで書き込み自粛してほしいわ
https://developer.mamezou-tech.com/blogs/2023/03/28/github-projects-new-roadmaps-layout/
はやくしないとGitHub Desktopに実装されるかもしれんぞ？
859デフォルトの名無しさん (ﾜｯﾁｮｲ 5b19-0WDc)
2023/08/23(水) 10:36:44.05ID:nEmftCML0860デフォルトの名無しさん (ﾜｯﾁｮｲ abe4-Xr9l)
2023/08/23(水) 10:52:27.60ID:niebTNUf0 >>859
857の記事にも書いてあるようにOSS関連の一部プロダクトはGitも使ってるらしい
857の記事にも書いてあるようにOSS関連の一部プロダクトはGitも使ってるらしい
861デフォルトの名無しさん (ﾌﾞｰｲﾓ MMb3-8Zil)
2023/08/23(水) 15:26:39.62ID:dqz/VE+aM862デフォルトの名無しさん (ﾜｯﾁｮｲ 2b63-Wp5N)
2023/08/23(水) 22:46:27.46ID:/k4AJPVh0863デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y)
2023/08/24(木) 06:55:26.94ID:RiZQ4RHb0 >>857
Piper/CitCがOSSまたはgoogleのサービスとして出てこないのは何故だろう？
Piper/CitCがOSSまたはgoogleのサービスとして出てこないのは何故だろう？
864デフォルトの名無しさん (ﾜｯﾁｮｲ 5b19-0WDc)
2023/08/24(木) 14:29:24.75ID:uKUnpR3b0 >>863
https://gist.github.com/peketamin/08fc44a0e8bed1d2ba6d9d193f9ba86c
>結論としては...社内専用システムを用意したりする余裕のない組織、ガバナンスの弱い組織、強い技術リードが
>いない組織は、単一レポは難しそう...
ということで、OSS向きではないらしい
ただ近い運用ならmainオンリーで使い続けリリースはメンテナーが強権でcherry pickで取捨選択してリリースブランチ
作るなら出来そう。
https://gist.github.com/peketamin/08fc44a0e8bed1d2ba6d9d193f9ba86c
>結論としては...社内専用システムを用意したりする余裕のない組織、ガバナンスの弱い組織、強い技術リードが
>いない組織は、単一レポは難しそう...
ということで、OSS向きではないらしい
ただ近い運用ならmainオンリーで使い続けリリースはメンテナーが強権でcherry pickで取捨選択してリリースブランチ
作るなら出来そう。
865デフォルトの名無しさん (ﾜｯﾁｮｲ 2b8f-mdXp)
2023/08/25(金) 00:31:50.60ID:epFqvsgF0 OSSにしたところで、短時間で数百ものコミットを行うGoogleエリートプログラマのマネなんかできないだろ
866デフォルトの名無しさん (ﾜｯﾁｮｲ 2bbb-Afo3)
2023/08/25(金) 05:00:12.06ID:dTY0c2Oa0 >>863
技術的な話として
基盤となっているオーバーレイ型の共有ファイルシステムはコストフルなので速いネットワークを要求する
拠点内か高速のネットワークで拠点間を繋がなければ遅くて使えたもんじゃない
つまり google 内だから使える仕組みであって一般に使えるものじゃない
ファイルシステム自体が企業秘密だしね
技術的な話として
基盤となっているオーバーレイ型の共有ファイルシステムはコストフルなので速いネットワークを要求する
拠点内か高速のネットワークで拠点間を繋がなければ遅くて使えたもんじゃない
つまり google 内だから使える仕組みであって一般に使えるものじゃない
ファイルシステム自体が企業秘密だしね
867デフォルトの名無しさん (ﾜｯﾁｮｲ 2bbb-Afo3)
2023/08/25(金) 05:22:43.53ID:dTY0c2Oa0 >>864
レビュー・システム経由でしかコミットできない仕組みなので git で言うなら
・全員がローカルの master ブランチで開発する
・できたらコミット1回分ごとにプルリクを送ってレビューしてもらう
・レビュー通ったら本番サービスに即自動反映する
みたいな運用だな。WEBシステム特有というかサービス・プロバイダー特化
レビュー・システム経由でしかコミットできない仕組みなので git で言うなら
・全員がローカルの master ブランチで開発する
・できたらコミット1回分ごとにプルリクを送ってレビューしてもらう
・レビュー通ったら本番サービスに即自動反映する
みたいな運用だな。WEBシステム特有というかサービス・プロバイダー特化
868デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y)
2023/08/25(金) 07:41:53.00ID:Wiq8Fw170 >>864
> 社内専用システムを用意したりする余裕のない組織
そういう会社こそ外部システムを必要とするわけだし、そいつは出来ない事にしたいだけだな。
モノリポが難しいわけではない。(むしろ簡単)
同様に分散が難しいわけでもない。(gitが無駄に難しく複雑なのは主に濱野がこの点では無能だからだろう)
なお、ソースコード履歴ツリーは、全く同じ運用がgitでも出来る。
(ただgitの推奨《＝みんながやってる形式》とは違うから、バグ踏む可能性もあるが)
>>866
そのままではCitcは無理なのは分かった。
ただ、ならgitと同様丸々コピーしてしまえば解決する。
世の中の全てを含んだモノリポではなく、関連する数個のリポの「マルチリポ」でも十分効果がある。
>>867
> WEBシステム特有というかサービス・プロバイダー特化
そうではないと思うがな。何故gitを使わないといけない事にしたいんだ？
gitは、Linus担当部分の「マージの効率化」が目的で、そこで発想が終了してる。
Piperは「アプリケーション開発全体の効率化」が目的で、当然「テスト」や「リファクタ」も含まれてる。
「依存関係」を見るには纏まってる方が便利だから、マルチリポ化を目指す事になる。
スケールメリットもあるので、速度に問題がなければ結果的にモノリポ化する。
何の開発でも「依存関係」の確認は必要だ。
結果的にマルチリポなら、mainリポ（＝本体)とsubリポ(＝依存関係を参照するだけ)に分離するだけで機能する。
googleって「ねえねえ僕ってすごいでしょ！！！入社してね！！！」みたいな方針のように見えるし、
社外にPiperモドキをリリースし、「続きはgoogleに入社してから！！！」な方が自然に感じる。
> 社内専用システムを用意したりする余裕のない組織
そういう会社こそ外部システムを必要とするわけだし、そいつは出来ない事にしたいだけだな。
モノリポが難しいわけではない。(むしろ簡単)
同様に分散が難しいわけでもない。(gitが無駄に難しく複雑なのは主に濱野がこの点では無能だからだろう)
なお、ソースコード履歴ツリーは、全く同じ運用がgitでも出来る。
(ただgitの推奨《＝みんながやってる形式》とは違うから、バグ踏む可能性もあるが)
>>866
そのままではCitcは無理なのは分かった。
ただ、ならgitと同様丸々コピーしてしまえば解決する。
世の中の全てを含んだモノリポではなく、関連する数個のリポの「マルチリポ」でも十分効果がある。
>>867
> WEBシステム特有というかサービス・プロバイダー特化
そうではないと思うがな。何故gitを使わないといけない事にしたいんだ？
gitは、Linus担当部分の「マージの効率化」が目的で、そこで発想が終了してる。
Piperは「アプリケーション開発全体の効率化」が目的で、当然「テスト」や「リファクタ」も含まれてる。
「依存関係」を見るには纏まってる方が便利だから、マルチリポ化を目指す事になる。
スケールメリットもあるので、速度に問題がなければ結果的にモノリポ化する。
何の開発でも「依存関係」の確認は必要だ。
結果的にマルチリポなら、mainリポ（＝本体)とsubリポ(＝依存関係を参照するだけ)に分離するだけで機能する。
googleって「ねえねえ僕ってすごいでしょ！！！入社してね！！！」みたいな方針のように見えるし、
社外にPiperモドキをリリースし、「続きはgoogleに入社してから！！！」な方が自然に感じる。
869デフォルトの名無しさん (ﾜｯﾁｮｲ 2bbb-Afo3)
2023/08/25(金) 09:01:15.40ID:dTY0c2Oa0 >>868
長文くんに理解できるように説明するのは難しそうだが、書いてみる
「世界中で動いているバージョンは一つだけ。古いのを動かすのは禁止。ベータ版みたいな未来のを動かすのは禁止。こうすることでバージョン違いによる整合性とかを考えなくて良くなる」
という割り切りをしたシステムだから。これは自社サーバーでのみプログラムを動かしてるから実現できる。
ユーザ側で動かすような android や chrome のような端末ソフトは複数バージョン並行で使われるので google でも git を使ってる
長文くんに理解できるように説明するのは難しそうだが、書いてみる
「世界中で動いているバージョンは一つだけ。古いのを動かすのは禁止。ベータ版みたいな未来のを動かすのは禁止。こうすることでバージョン違いによる整合性とかを考えなくて良くなる」
という割り切りをしたシステムだから。これは自社サーバーでのみプログラムを動かしてるから実現できる。
ユーザ側で動かすような android や chrome のような端末ソフトは複数バージョン並行で使われるので google でも git を使ってる
870デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y)
2023/08/25(金) 12:52:05.16ID:Wiq8Fw170871デフォルトの名無しさん (ｱｳｱｳｸｰ MM8d-1fKg)
2023/08/25(金) 14:24:47.15ID:9wWAHqbcM 具体的に書けないのは印象操作に見られても仕方ない
872デフォルトの名無しさん (ﾜｯﾁｮｲ 599c-RKQT)
2023/08/25(金) 15:05:23.64ID:BaamFBf70873デフォルトの名無しさん (ﾜｯﾁｮｲ 1563-9oWV)
2023/08/27(日) 14:35:48.07ID:NDLPFvxJ0874デフォルトの名無しさん (ﾜｯﾁｮｲ fe19-vHpx)
2023/08/28(月) 17:00:34.15ID:lGu1ZxjR0 それ以前にGitスレなのだからGit使ってる人しか来ないってことに、まだ気づかないのだろうか？
875デフォルトの名無しさん (ﾜｯﾁｮｲ eae4-VBPx)
2023/08/28(月) 22:42:01.73ID:iaZNrcir0 なんか他のブランチから引っ張って来ようとしたら競合が起きてチェリーピック出来ないんだけど、何が悪いんだろ？
あんまり見ずに時間切れになったからまた明日調べるつもり
存在しないものを削除しようとしてるとかあるのかな？
あんまり見ずに時間切れになったからまた明日調べるつもり
存在しないものを削除しようとしてるとかあるのかな？
876デフォルトの名無しさん (ﾜｯﾁｮｲ 06bb-yFzu)
2023/08/28(月) 23:40:30.70ID:diChUi9T0 >>875
コンフリクトが起きるのは特に問題ないのでは？
コンフリクトではなくてコマンド自体が弾かれてるなら、worktree か index に変更中のファイルが残ってる可能性が大。
まずはそいつらをどうにかしてから cherry-pick してみたら
コンフリクトが起きるのは特に問題ないのでは？
コンフリクトではなくてコマンド自体が弾かれてるなら、worktree か index に変更中のファイルが残ってる可能性が大。
まずはそいつらをどうにかしてから cherry-pick してみたら
877デフォルトの名無しさん (ﾜｯﾁｮｲ fe19-vHpx)
2023/08/29(火) 08:47:58.69ID:bkg5tMQT0 >>875
git stashで現状のソースを一時退避したあと、綺麗な状態にしてからcherry-pickして、stashの内容を復元したら？
git stashで現状のソースを一時退避したあと、綺麗な状態にしてからcherry-pickして、stashの内容を復元したら？
878デフォルトの名無しさん (ｱｳｱｳｳｰ Sa47-bpS4)
2023/09/11(月) 13:00:51.18ID:lXcI/Ajda >>875
存在してるものでも削除する
存在してるものでも削除する
879デフォルトの名無しさん (ﾜｯﾁｮｲ fae4-sAKC)
2023/09/11(月) 22:07:33.10ID:F9+U7gZ/0 >>876-878
ありがとう、どうも更新の順番が逆だったみたいだ、お騒がせしました
ありがとう、どうも更新の順番が逆だったみたいだ、お騒がせしました
880デフォルトの名無しさん (ﾜｯﾁｮｲ 0fe6-mbMR)
2023/09/20(水) 15:05:17.00ID:aE0319zM0 TortoiseGitを使って、SVNのリポジトリをGitに変換してみたけど、
SVNとの併用が想定されているのか、タグがブランチのままだったり、
trunkという名前のブランチができていたり、思っていたのとちょっと違う結果でした。
完全一方向でよいのだけど、Windowsで綺麗に変換できるツールはありませんか？
SVNとの併用が想定されているのか、タグがブランチのままだったり、
trunkという名前のブランチができていたり、思っていたのとちょっと違う結果でした。
完全一方向でよいのだけど、Windowsで綺麗に変換できるツールはありませんか？
881デフォルトの名無しさん (ﾜｯﾁｮｲ 8f84-Z/H0)
2023/09/20(水) 23:39:58.91ID:7IB3hYyU0 >>880
ベースになるgit-svnがそういう変換動作だから仕方ないんじゃないの
ベースになるgit-svnがそういう変換動作だから仕方ないんじゃないの
882デフォルトの名無しさん (ﾜｯﾁｮｲ 7fbb-mga4)
2023/09/21(木) 02:20:33.87ID:yIhcH/cG0 >>880
svn と git は思想が違うので完全に一対一で移行するのはむずかしい。結局 svn をどういうルールで運用していて、それを git でどういう形に移行したいかは人によって違うので。
自分でスクリプト書いて移行しちゃうのが結局は楽だと思う。
svn と git は思想が違うので完全に一対一で移行するのはむずかしい。結局 svn をどういうルールで運用していて、それを git でどういう形に移行したいかは人によって違うので。
自分でスクリプト書いて移行しちゃうのが結局は楽だと思う。
883デフォルトの名無しさん (ﾜｯﾁｮｲ 0fe6-mbMR)
2023/09/21(木) 08:55:56.61ID:PwcZbKtJ0884デフォルトの名無しさん (ﾜｯﾁｮｲ 7fbb-mga4)
2023/09/21(木) 09:51:45.73ID:yIhcH/cG0885デフォルトの名無しさん (ﾜｯﾁｮｲ 3ff9-ieJ7)
2023/09/21(木) 10:22:17.06ID:9EJ/22eM0 こだわりあるみたいだし自分で調整するのが一番早いだろうね
ブランチ名変えるとかタグ付けてブランチ消すとか最低限覚えといて損しないコマンドだし
移行したいタグが大量にあったとしても、繰り返し処理とかプログラミングしなくたってアナクロなコピペ編集でコマンドを一杯こさえて一気に流せばよい
タグの一覧をコマンド等で出してそれをベースにVSCodeのマルチカーソルなりExcel関数なりなんならサクラエディタの置換なり
必要なコマンドを3つ4つ覚えればあとは30分あれば初めてでもできる
ブランチ名変えるとかタグ付けてブランチ消すとか最低限覚えといて損しないコマンドだし
移行したいタグが大量にあったとしても、繰り返し処理とかプログラミングしなくたってアナクロなコピペ編集でコマンドを一杯こさえて一気に流せばよい
タグの一覧をコマンド等で出してそれをベースにVSCodeのマルチカーソルなりExcel関数なりなんならサクラエディタの置換なり
必要なコマンドを3つ4つ覚えればあとは30分あれば初めてでもできる
886デフォルトの名無しさん (ﾜｯﾁｮｲ 3f5c-xbk3)
2023/09/21(木) 10:39:02.85ID:144VeT0R0 >>883
公式サイトにそれっぽいのがあったけどこれは見たの?
https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git
ちゃんと読んでないけどgit svn cloneからタグの話とtrunkブランチの話をしてるっぽく見えるよ?
公式サイトにそれっぽいのがあったけどこれは見たの?
https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git
ちゃんと読んでないけどgit svn cloneからタグの話とtrunkブランチの話をしてるっぽく見えるよ?
887デフォルトの名無しさん (ﾜｯﾁｮｲ 0fcf-hKjy)
2023/09/21(木) 11:17:57.92ID:184B7ywA0888デフォルトの名無しさん (ﾜｯﾁｮｲ ff19-Pa4f)
2023/09/21(木) 18:31:50.78ID:5KTS95Cm0 >>880
GitHubにすでに作った。という前提で話すけど、Web画面から手動で「main」ってブランチ作って、Trunkから
mainにプルリクエスト作って自分でマージしてTrunkはまだ削除せず、しばらく残しとけばいいのでは？
で、Settings の Default branch を「main」にする
あとはSVNから移行が終わったタイミングで折を見てTrunkブランチを閉じる
そしたら後はorigin/mainを親リポジトリで作業進める
※個人の趣味で「master」にしたいなら、mainのところを置き換えてね
あと個人でしか使用しなくて publicにしたいのにprivate だった場合は、
Danger Zone の Change repository visibilityでChange to publicにする
逆に社用なのにpublicになってたらChange to privateに
ツールならGitHub DesktopでもSourceTreeでもTortoiseGitでもお好きなのを
LinuxならGitHub Desktopしかない気がする
GitHubにすでに作った。という前提で話すけど、Web画面から手動で「main」ってブランチ作って、Trunkから
mainにプルリクエスト作って自分でマージしてTrunkはまだ削除せず、しばらく残しとけばいいのでは？
で、Settings の Default branch を「main」にする
あとはSVNから移行が終わったタイミングで折を見てTrunkブランチを閉じる
そしたら後はorigin/mainを親リポジトリで作業進める
※個人の趣味で「master」にしたいなら、mainのところを置き換えてね
あと個人でしか使用しなくて publicにしたいのにprivate だった場合は、
Danger Zone の Change repository visibilityでChange to publicにする
逆に社用なのにpublicになってたらChange to privateに
ツールならGitHub DesktopでもSourceTreeでもTortoiseGitでもお好きなのを
LinuxならGitHub Desktopしかない気がする
889デフォルトの名無しさん (ﾜｯﾁｮｲ 0fe6-sMWx)
2023/09/22(金) 12:25:38.45ID:zqcoLnA20 >>884-888
みなさんありがとうございます。
TortoiseSVNやTortoiseGitやSourceTreeのGUIのみでやってきたので、
コマンドとかスクリプトとかが絡んでくると諦めそうになりますが、いろいろ試してみます。
みなさんありがとうございます。
TortoiseSVNやTortoiseGitやSourceTreeのGUIのみでやってきたので、
コマンドとかスクリプトとかが絡んでくると諦めそうになりますが、いろいろ試してみます。
890デフォルトの名無しさん (ﾜｯﾁｮｲ 7fbb-mga4)
2023/09/22(金) 14:07:04.05ID:QgJpwCFm0891デフォルトの名無しさん (ﾜｯﾁｮｲ 4d02-+cLA)
2023/09/30(土) 06:21:53.24ID:QeOF2WAv0 (*ノ・ω・）ノオオオオォォォォ
892デフォルトの名無しさん (JP 0Hd1-tvb5)
2023/09/30(土) 20:34:11.62ID:T95KWQ43H origin/branchとする場合と、origin branchとする場合が混在してて分かりにくいわ
設計がでたらめなんだろうな
設計がでたらめなんだろうな
893デフォルトの名無しさん (ﾜｯﾁｮｲ cbbb-s7v3)
2023/09/30(土) 21:49:53.62ID:YLnuUfaR0 >>892
別のものを指してるんだよ。
origin/branch は remotes/origin/branch の略でただのブランチ名。ローカルにあるリモート・ブランチのコピーを指す。ほとんどのコマンドで使える。ネットワーク切れててもアクセス可能。最新版じゃないかもしれない。
origin branch は特定のコマンドだけで受け付ける形式で、リポジトリ名とブランチ名の2つを指定して、ネットワークの先にあるリモート・ブランチそのものを指す。
その特定のコマンドでローカルにコピーを作って、コピーを操作するというのが git の思想。マニュアルか良い参考書を読め。
別のものを指してるんだよ。
origin/branch は remotes/origin/branch の略でただのブランチ名。ローカルにあるリモート・ブランチのコピーを指す。ほとんどのコマンドで使える。ネットワーク切れててもアクセス可能。最新版じゃないかもしれない。
origin branch は特定のコマンドだけで受け付ける形式で、リポジトリ名とブランチ名の2つを指定して、ネットワークの先にあるリモート・ブランチそのものを指す。
その特定のコマンドでローカルにコピーを作って、コピーを操作するというのが git の思想。マニュアルか良い参考書を読め。
894デフォルトの名無しさん (JP 0Hd1-tvb5)
2023/09/30(土) 21:58:44.23ID:T95KWQ43H それが設計の甘さだろ
素人設計っぽいし
素人設計っぽいし
895デフォルトの名無しさん (ﾜｯﾁｮｲ cbbb-s7v3)
2023/09/30(土) 22:14:28.90ID:YLnuUfaR0 >>894
これより良い設計があると思うならお前が作ってみせろ。俺が今から作っても同じ設計になるわ
これより良い設計があると思うならお前が作ってみせろ。俺が今から作っても同じ設計になるわ
896デフォルトの名無しさん (ﾜｯﾁｮｲ cb63-oFT1)
2023/09/30(土) 22:31:26.06ID:rV95YYF80 おかえり？
897デフォルトの名無しさん (JP 0Hd1-tvb5)
2023/09/30(土) 23:20:55.81ID:T95KWQ43H >>895
別にいいけど、見積してほしいなら営業経由でお願いします
別にいいけど、見積してほしいなら営業経由でお願いします
898デフォルトの名無しさん (ﾜｯﾁｮｲ cbbb-s7v3)
2023/09/30(土) 23:21:44.57ID:YLnuUfaR0 >>897
営業の連絡先教えて
営業の連絡先教えて
899デフォルトの名無しさん (ﾜｯﾁｮｲ 9b47-zhxJ)
2023/10/01(日) 00:26:47.74ID:M5IYUQLy0 Linusを素人呼ばわりする人の実績を知りたい
900デフォルトの名無しさん (ﾜｯﾁｮｲ 7de7-bfQx)
2023/10/01(日) 11:56:13.91ID:a3kOBeCu0 >>892
基本的にリモートリポジトリから何かしたいコマンドはorigin branch
それ以外、つまりローカルブランチも対象になるコマンドの場合はorigin/branch
pull/fetch/pushはローカルリポジトリに対して行うコマンドでないことは明白だろう、だから前者を使う
基本的にリモートリポジトリから何かしたいコマンドはorigin branch
それ以外、つまりローカルブランチも対象になるコマンドの場合はorigin/branch
pull/fetch/pushはローカルリポジトリに対して行うコマンドでないことは明白だろう、だから前者を使う
901デフォルトの名無しさん (ﾜｯﾁｮｲ b55f-VEJP)
2023/10/02(月) 09:35:59.77ID:gcnNh1oY0 20年振りに自分でプログラミングするんだけどGitの概念がわからなすぎて辛い・・・
リポジトリだのブランチだのステージングだのコミットだの今までの言語概念になかった用語多すぎて覚えきれない
今のプログラマ仕事のPG以外にどんだけ難しいことやらされてるの・・・
リポジトリだのブランチだのステージングだのコミットだの今までの言語概念になかった用語多すぎて覚えきれない
今のプログラマ仕事のPG以外にどんだけ難しいことやらされてるの・・・
902デフォルトの名無しさん (ﾜｯﾁｮｲ 1b19-7Zbx)
2023/10/02(月) 10:33:16.49ID:wO0OiMMg0 そういう場合はGUIのGitツール使えばいいと思うよ。
ただしコンフリクトの修正観念だけは知ってないと、にっちもさっちも行かなくなるしSourceTreeや
Github Desktopみたいにリポジトリを回復するためにgit stash相当を実行しますみたいなコマンドに
「はい」を選択すると、自分の修正したソースがきれいさっぱりなくなって絶望することになるけど。
実は自分の修正差分は退避されてるだけなので復帰は十分可能なんだけど新人さんはパニくる。
ただしコンフリクトの修正観念だけは知ってないと、にっちもさっちも行かなくなるしSourceTreeや
Github Desktopみたいにリポジトリを回復するためにgit stash相当を実行しますみたいなコマンドに
「はい」を選択すると、自分の修正したソースがきれいさっぱりなくなって絶望することになるけど。
実は自分の修正差分は退避されてるだけなので復帰は十分可能なんだけど新人さんはパニくる。
903デフォルトの名無しさん (ﾜｯﾁｮｲ 1b19-7Zbx)
2023/10/02(月) 10:33:19.63ID:wO0OiMMg0 そういう場合はGUIのGitツール使えばいいと思うよ。
ただしコンフリクトの修正観念だけは知ってないと、にっちもさっちも行かなくなるしSourceTreeや
Github Desktopみたいにリポジトリを回復するためにgit stash相当を実行しますみたいなコマンドに
「はい」を選択すると、自分の修正したソースがきれいさっぱりなくなって絶望することになるけど。
実は自分の修正差分は退避されてるだけなので復帰は十分可能なんだけど新人さんはパニくる。
ただしコンフリクトの修正観念だけは知ってないと、にっちもさっちも行かなくなるしSourceTreeや
Github Desktopみたいにリポジトリを回復するためにgit stash相当を実行しますみたいなコマンドに
「はい」を選択すると、自分の修正したソースがきれいさっぱりなくなって絶望することになるけど。
実は自分の修正差分は退避されてるだけなので復帰は十分可能なんだけど新人さんはパニくる。
904デフォルトの名無しさん (ﾜｯﾁｮｲ 1b19-7Zbx)
2023/10/02(月) 10:36:05.48ID:wO0OiMMg0 すまん。大事でもないのに2回も送信を。
レス数が900を超えています。1000を超えると表示できなくなるよ。
