Git 19

2022/11/06(日) 16:40:27.51

ソースコード管理を行う分散型バージョン管理システム、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

2023/08/19(土) 13:51:27.18

>>791
> ここまでの作業で気づいた間違いは自分以外の人に影響を与えることは全く無い
それはどんな環境でも同じだよ。
違いは提出物がファイルかリポジトリかで、一つのファイルしか触ってないのならファイル提出の方が断然楽だ。

しかもお前ら、
> そのローカルブランチをそのまんまメインリポジトリのブランチにワンタッチで昇格できる
は禁止なんだろ？
仮にパッチを作成するのに10日間かかったとして、
1日目(○○やります！！！)、2日目、、、10日目(完成しました！！！)、というコミットではなく、
最終的にrebaseして一発で最終状態(10日目の結果)を生成したと改竄した履歴をローカルリポジトリに作り、それを提出しろ、と言うんだろ。
なら意味ねーじゃん。

2023/08/19(土) 14:20:20.06

いいから一度ちゃんとGit使えって
もう業界のデファクトスタンダードなんだって
お前めっちゃ恥ずかしい発言を連発してんだぞ

2023/08/19(土) 14:41:38.83

>>789
プログラム書けないやつはこれだから……

・複数の実装を書いて比較してみたいことがある
・機能の組み合わせを複数パータンでテストしたいことがある
・新しい発想を他に影響を与えずに試したいことがある
・新規提案前に実物を作って見せたいことがある
・開発を複数並行で進めなくてはいけないこともある
・緊急の割り込みタスクが入ることがある
・自分の仕事の合間に他の人の仕事を助けてやることがある
・やっつけで書いたコードを他人に見せる前に綺麗に清書するのは当然、しないやつは○ね
・テストなどで出た問題は他人に見せる前に直すのが普通
・タイポとか恥ずかしい間違いは他人に見せれない。見せられた方も困る

まだまだ書けるけど？

2023/08/19(土) 15:09:35.75

長文くんは試行錯誤なんてできないからな
「バケツ」のときも、つくるのなら試行錯誤するしかないから
そうしろと言われたら「迫害された」と叫んで逃げ出したし

2023/08/19(土) 15:12:04.16

>>793
おまえは勘違いしているというか、gitのブランチとリポジトリを理解できてない
「ローカルブランチをそのまんまメインリポジトリのブランチにワンタッチで昇格」これを禁止してるところはほとんど無い
プルリクエストで管理者がチェックしてメインブランチにマージする現場でも、まずはローカルブランチをメインのリポジトリにpushしてチェックしてもらうんだから

2023/08/19(土) 15:21:01.19

>>793
提出物がファイルではなくてソース環境のほぼ完全なスナップショットであるブランチなのが重要なのだよ
それを誰への影響もないローカルなリポジトリで作って他人が閲覧可能なリモートへ簡単に昇格できる
svnは途中から近いことができるようになったがcvs以前では考えられないような便利な仕組み

2023/08/19(土) 15:41:12.22

>>793
ぜんぜん分かってないな。例を挙げると

A機能の追加
A機能のバグ修正
B機能の追加
A機能の変数名変更
B機能のスペルミス修正
C機能の追加
B機能のアルゴリズム変更
A機能のバグ修正
A機能とC機能の共通部分のくくり出し
共通部分を使うようA機能を変更
共通部分を使うようC機能を変更
C機能の拡張
C機能のコメントのタイポ修正
不要になったB機能の削除
A機能のコード整理

という作業を1日に手元でやって、15回のコミットがローカルブランチに入ってるとして、これを共有前に

共通部分の追加
A機能の追加
C機能の追加

という3回のコミットに直して、それぞれに丁寧なコミットログ書いて、こっちだけを共有するんだよ。他の人がレビューしたり再利用する時間が大幅短縮できる。
git ならコマンド1つでこの「直し」ができる。これをやらないのは、他人の時間を湯水のように使っても許されると思ってるバカだけ。
他でもやるべきだが、git みたいにコマンド一発とはいかないので超面倒。結局ぐちゃぐちゃなのが共有されたりする

2023/08/19(土) 16:15:13.73

>>795
それ全部、ブランチ無くてもローカルでコピーすれば出来る案件だろ。
実際、git以前でも出来たけど、何故出来ないと思ってるの？
お前、共有リポジトリを生でいじるガイジか？

ブランチはある意味そういったコピー履歴/ドタバタ履歴をリポジトリ内に記録する為の機能であって、
後で改竄してそういったドタバタなんて無かったことにするのなら、必要ないんだよ。
最終状態のファイル群をmasterに繋げていけば済むんだから。そしてgitが推奨してるのはこれだろ。

>>797
> 禁止してるところはほとんど無い
綺麗な履歴なら、だろ。
そして>>799のように綺麗な履歴にするのがmustなんだろ。

俺が残したい履歴は
> 結局ぐちゃぐちゃなのが共有されたりする(799)
と表現されてる方だから、gitは俺には(と言うよりもコードを書く人にとっては)合わないし意味がない、というわけ。
(ただまあ《マージしかしない》Linusにとっては「ぐちゃぐちゃ」してる部分は意味がないのも事実なので、
《自分専用機を作っただけの》彼がこの機能を意図的に落としているように見えるが、
それにつき合わされてgitを崇拝してる連中は頭がおかしいとしか思えない。
お前にとって残したい履歴は何？という話)

逆にHgとかはこの「ぐちゃぐちゃ」な履歴を保持するポリシーなのかな？
あちらは履歴の改竄は禁止だと聞いているので。
誰か知ってたら教えて。

2023/08/19(土) 16:53:04.38

>それ全部、ブランチ無くてもローカルでコピーすれば出来る案件だろ。

だから何だというんだろう。ブランチ使わずにできるからコピーで頑張りましょうってか？

2023/08/19(土) 17:16:31.29

>>800
ちゃんと調べたか？
git も hg も同じだよ。そのためのローカルブランチなんだから
どっちも共有リポジトリの改竄は禁止、やったやつは腹を切れ。ローカルはお前にしか影響ないんだから好きにしろ。

2023/08/19(土) 17:25:39.06

> お前にとって残したい履歴は何？という話)

結局、プログラムしたことないので個人で残したい履歴と、共有で残したい履歴は違うということが理解できないんだな。

タイポの修正履歴とかは他の人にとってはノイズでしかないので共有不要。自分の手元にだけ残っていれば良い。タイポ修正前のコードを見たいやつはいない。
多人数で開発する場合はノイズが少ないほど開発効率が上がるしバグも少なくなる。

2023/08/19(土) 17:58:00.64

>>800
最終成果物としてマージする目的のブランチの他にも、まだ作業中で整理していないブランチもメインリポジトリで共有するぞ

作業方針をレビューする目的とか、お前みたいに口ばっかで全然作業が進まないやつをキツめにフォローする目的とかでな

2023/08/19(土) 21:34:40.48

>>802
いや調べてない。以下読んだだけ。
> Mercurialは「履歴は永久的で神聖である」という哲学を持っていて、
> 履歴を操作するコマンドとしては1種類しかありません。
> その一方で、Gitは履歴を操作できる範囲が広いという違いがあります。
> https://tracpath.com/works/development/git-mercurial-subversion/
だから、多分、君らが思ってるほど同じじゃないんだよ。gitは履歴改竄する前提だ。

> どっちも共有リポジトリの改竄は禁止、やったやつは腹を切れ。ローカルはお前にしか影響ないんだから好きにしろ。
これは当たり前で、俺が言ってるのはこれではなく、
「ぐちゃぐちゃ」の履歴を保持する文化があるか、ということ。次レス以降参照

2023/08/19(土) 21:36:21.23

>>803
> 個人で残したい履歴と、共有で残したい履歴は違う
> 自分の手元にだけ残っていれば良い
これらはその通りだが、gitにはこれを残す方法が用意されてないだろ。(まあsvn等も同様だとも思うが)
お前は一々別に残せと言うのか？
799通りやってたら既にそれがgitに記録されてるのに？(1回目)
そして共有用に履歴を改竄して、(2回目)
またどこか別にオレオレ用履歴を記録し直すなりしろと？(3回目)
三度手間だろ。
お前らの言う「グチャグチャな」履歴(1回目)を提出すれば(2回目)(3回目)はやらなくて済む作業だよ。

そしてそもそも履歴の哲学が間違ってる。
gitは「歴史か物語か」と嘯いてるが、これは90年代のPCが非力なときの思想であって、
履歴は「全部記録した上で表示時に間引く」と結論は出てて、他も全部そうなってるだろ。
(テキストで言えば>>logしてgrepする)
後になって確認するときにならないと、何が必要だったか分からないものだからだよ。

綺麗に改竄された履歴があったとして、仮に修正漏れがあったとき、
何故修正が漏れたのか、どこで対応し損ねたか、反省も出来ないだろ。
タイポの記録なんて馬鹿げてると思うのなら、タイポしないように注意しろという話であって、
タイポ記録まで含めて記録されてれば、
後から「ああ俺はあのときはこんなにタイポしてたのか、ずいぶんマシになったな」というのも分かるだろ。
小綺麗な記録だけ残ってても大して役に立たない。
記録は「できるだけ情報を削らない」のが大原則だ。
gitはこの辺が根本的に間違ってる。思想が古すぎる。
「歴史か物語か」は、適切にgrepする機構が足りてないのを誤魔化してるだけ。
それで騙されてるお前らはお花畑過ぎる。

2023/08/19(土) 21:38:13.61

>>804
それが技術的に出来るのはみんな知ってるよ。
問題は上述の通り、それをやったときに適切にgrepする機構がないから、
最初からgrepした結果になるように履歴を改竄した上でpushしろ、という文化な事。
マージするLinusの都合だけで作ってある。
だからコードを書く側の俺はgitには相当違和感があるし、
805内URLの人もそうだからMercurialとは違うと書いてるのだと思う。
そしてお前らにこの方面の感度が皆無なのは、お前らがコードを書いてないからだとも思う。

まあこれはいい。それで、
> まだ作業中で整理していないブランチもメインリポジトリで共有する
で運用するとして、その先はどうするんだ？
整理したらブランチ消すのか？なら手間が増えてるだけだろ。
svnのブランチ、「ディレクトリがブランチになります！！！」と言い切るのはどうなのよ？とも思うが、
実際、svnなら中途半端なコードを各ブランチに上げられても他の人は全く手間は増えないよ。
のろま君が勝手にコピーしてろで終わりだ。
gitの場合は、のろま君をフォローする為に中央リポジトリが毎日更新されてた場合、
(大した手間ではないが)pushする前にまず中央リポジトリと同期しなければならなくなり、
のろま君の為に全員に手間が増えてる。
これは、分散型のgitで集中管理を行おうとしたから発生したオーバーヘッドであり、
集中型のsvnだったら発生しなかった手間だ。
だから当たり前だが、集中型の開発管理を行うのなら集中型のリポジトリの方が適切だということ。
そして大半のプロプライエタリは集中型の開発なので、ゲーム会社が積極的にgitに移行する理由がない。
(というか連中はここら辺のgitの問題を分かってるから移行してないと思うんだよ。
お前らみたいにgitを理解出来ないから移行出来ないのだ！とかいう、
「上から目線ガー」とかうるさい割には心の中では心底他人を馬鹿にしてるゆとりマインドでは理解不能かもしれんが)

2023/08/19(土) 21:45:36.49

コミットが開発プロセスの資産であることを本質的にわかってないんだろうね
うちのプロジェクトのメンバーにもそういう人がいるんだよね
毎回説明しても理解してくれない…

2023/08/19(土) 22:22:25.04

>>808
コードが資産で、コミットやgitでの管理は手段だよ。
それは典型的な手段の目的化であり、お前が間違ってる。

ユーザーが求めてるのは、新規機能の実装やバグの修正であって、
綺麗なcommit履歴のgitリポジトリではない。

と毎回説明しても理解してくれない…とそいつも思ってるだろうよ。

2023/08/19(土) 22:41:56.92

>ユーザーが求めてるのは、新規機能の実装やバグの修正であって、

gitを使ってそれができているならなんの問題もないわけだがあんたはいったいなにを主張したいんだろうか

2023/08/19(土) 22:55:00.77

>>806

>> 個人で残したい履歴と、共有で残したい履歴は違う
>> 自分の手元にだけ残っていれば良い
> これらはその通りだが、gitにはこれを残す方法が用意されてないだろ。

わざわざ消さなければ残っているのにどうして別の方法が必要なんだ？

>履歴は「全部記録した上で表示時に間引く」と結論は出てて、他も全部そうなってるだろ。

お前の脳内結論とか持ってこられても開発効率は上がらないんだよ。複雑なバグの追跡やコードの再利用には綺麗な履歴が必須。

2023/08/19(土) 22:57:43.95

>>809
なんで資産かどうかの話にユーザが出てくるんだよ
もしかして資産は全てユーザに公開されるものだと思ってる？プロダクトの話ではなくて開発プロセスの資産の話だぞ

2023/08/19(土) 23:16:41.01

>>807
みんなは知ってる
でもお前は知らなかった
複数履歴に跨るようなgrepもできるのをお前はしらない
知らないのはおまえだけ

2023/08/19(土) 23:17:28.06

>>807
svn 使ったことないのに、知ってる風を装って語るので嘘杉て笑いが止まらない。
push する前に同期が必要なのが git
commit する前に同期が必要なのが svn
理解できるかな？無理だろうな。

2023/08/19(土) 23:19:47.05

>>807
作業中のブランチをレビューするのにメインリポジトリで共有するのはそれが簡単だから
レビューするのに最新の状態との同期とか必用無いし
作業前の状態との比較も簡単にできるし
そのままで問題なさそうなら最終成果物としてマージできるように同期して調整するのも簡単
必要無くなったら消すのも簡単
お前の妄想する手間がかかるから無駄とかこの機能を使わない理由のなんの説明にもなっていない
お前は理解できてないから手間がかかるとか無駄とか妄想を垂れ流す

2023/08/19(土) 23:21:47.54

>>814
いやgitはpushする前に同期は必須ではない
同期が必要な場合と必要でない場合を理解できて一人前

2023/08/19(土) 23:38:08.78

>>816
ごめん。何を言ってるのか分からない。まさか push -f しろと主張してるの？

2023/08/19(土) 23:43:08.38

>>817
オレが多分話の流れを読んで無いだけだと思うけど、push前に同期が必須かと問われたら
、同期が必須なのは他人がpushする可能性があるブランチだけと答える

2023/08/19(土) 23:51:47.78

>>818
なら単に用語の問題だな
git の push はブランチ単位での同期を要求する。push するブランチの同期が取れてるなら当然それ以上同期コマンドを実行する必要はない。
svn の commit はチェックアウトした範囲全体の同期を要求する。リポジトリ全体をチェックアウトしたなら全体の同期が必要。

まあどっちもとりあえずやってみて、失敗したら同期コマンド打てば良いだけだけどな

2023/08/20(日) 00:58:08.93

>>813
では何故改竄された綺麗な履歴を欲しがる？
俺なら799の場合は

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

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

2023/08/20(日) 01:06:37.87

>>820
じゃあ、ゴミログ残して、お前このあと C は必要だが A は別の機会にってなったときに簡単に対応できるか？
後から他人のゴミログ追いかけて必要な部分と不要な部分切り分ける手間暇馬鹿にならないし、ミスする確率も増える

2023/08/20(日) 01:49:04.21

>>820
綺麗な履歴とお前の言うgrepが関係あるといのは、お前の思いこみ妄想

綺麗な履歴を作らないようなプロジェクトもたくさんある

2023/08/20(日) 04:04:05.06

長文くんの考えは全部捨てずに突っ込んでおけば必要なものは探し出せるはずで
整理整頓なんか不要だし見た目が悪くても気にしないしそれで他の人が困ろうとどうでもいい
というゴミ屋敷理論だからなあ

2023/08/20(日) 08:34:32.23

>>821
簡単に対応する必要がないんだよ。

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

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

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

2023/08/20(日) 08:35:35.57

>>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の「清書」を作成だ。これが最大効率だ。
高い確率で必要ない「清書」を毎回ご丁寧にやる意味はない。

2023/08/20(日) 08:44:51.44

マージ側に都合がいいというのは正しいかもね。日頃からその視点を持って作業したら。

2023/08/20(日) 08:56:28.01

>>824
だから git 使えば清書は 10秒でできる。
2時間かけるのは馬鹿らしいって話。

2023/08/20(日) 08:58:29.28

長文さんは共同開発プロジェクトにgit使ったこと無いんじゃないかな。
むか～しに共同開発プロジェクトに参画させてもらった記憶だけで長文書いてそう。
こんなごちゃごちゃ口だけやかましい奴はプロジェクト推進の邪魔だから当時退場させられたんだろう多分

2023/08/20(日) 09:56:03.93

現実を見ていない妄想まみれのレスは置いといて、gitで清書したコミットだけをpushする方法ってあるのかしらん？

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

2023/08/20(日) 10:16:43.69

cherry-pick

2023/08/20(日) 10:17:14.38

>>826
だからgitはマージ専用機であり、gitを使えばマージの効率は上がる。
ただそれは多数側のコード書いてる担当者に負担を押しつけた結果だから、アプリケーション全体の開発効率は下がる。

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

2023/08/20(日) 10:35:23.52

>>829
多分、すごい古い git を使ってたんじゃないかな？
最近のはデフォルトが変更されていて、現在のブランチだけが push されるので他のものは push されないよ（オプションか設定変更で変えれる）

2023/08/20(日) 10:38:38.99

>>831
開発効率が下がるのは清書に2時間かけちゃう、お前だけだろ？

2023/08/20(日) 10:54:29.71

>それをせずに後付でAはやっぱり止めろ、と言うのはマネジメントの失敗であり、

前にもうまくマネジメントすればブランチは不要てなことを書いていたと思うが
それをやるのにかかるコストのことは考えてるんかね。

2023/08/20(日) 11:07:43.43

完璧な計画が作れないのはバケツであなたが体験した通りですよ

2023/08/20(日) 12:15:53.56

他人が10秒でやる仕事に2時間かけるのは無能
無能を棚に上げて、マネージメントのせいにして仕事拒否するとか、馬鹿を通り越して害悪

2023/08/20(日) 12:27:33.60

>>832
そうなのか……ありがと。
後で試してみる。

2023/08/20(日) 13:18:50.21

>>834
その程度のコストは普通の会社なら当たり前のようにかけてる。というか、そうじゃないと成立しない。

当たり前だが担当に振る前に、振る側は、担当の実力と、修正箇所の概略は把握してる。
だから「Aの担当モジュールだからAにやらせる」とか、
「この修正は難しいからBにやらせる」とかの判断が出来る。
この過程で、ファイル○○はAとBが変更する可能性がある、というのも分かるから、
Aに先にやらせてその後にB、程度の交通整理でマージの回避も出来る。

対してLinuxの場合は本質的にこれが出来ない。
パッチを送ってくる奴等の実力もさっぱり予測出来ないし、指示も強制も出来ない。
これは従来の伽藍開発ではあり得なかった状況なので、従来のvcsでは全く対応出来ず、gitを作った。

つまりLinusは「無重力でも書けるボールペン」として「無マネジメントでもマージ出来る」gitを作り、
従来の会社は、「Aに先にやらせる」程度のマネジメントで「一方ロシアは鉛筆を使った」が成立してる。
(つまり、集中型のvcsはある程度マネジメントがある前提でしか成立しない)

2023/08/20(日) 13:19:06.52

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

2023/08/20(日) 13:59:49.47

バケツくんと長文くんがいるように見えるのは僕だけかい？

2023/08/20(日) 14:17:18.15

バケツくんは、後で別のプログラマが自分のコミットを参照したり再利用することを考えないんだろうな
人に見せることを考えないので、自分が作業したありのままを残すことに執着する

あとrebaseを行って"清書"を行う自信がないんだろう笑
使ったことがないから笑

2023/08/20(日) 14:19:19.55

>(つまり、集中型のvcsはある程度マネジメントがある前提でしか成立しない)

まあその通りだな。で、あんたの要求するレベルの「マネジメント」にパワーをかけたくない現場は
ブランチ使って並行作業するだけ。

>ユーザーが求めてるのは、新規機能の実装やバグの修正であって、

そういうことだな。

2023/08/20(日) 15:33:57.12

>>824
タイポの記録をそのまま見せても何も改善できんわな
いつか役にたつかもしれない、役にたたないと断言できない
と考えて捨てられないゴミ屋敷理論だろ

>>825
その考えでうまくいくかどうか「バケツ」をつくって示せばいいのにつくれず
能書きをたれ続けるだけの長文くん

2023/08/20(日) 19:24:45.17

github desktopでもsourcetreeでもいいから変更履歴を複数選択してsquashかけたらあっという間に
履歴をまとめられるのも知らんのだろうな。

2023/08/20(日) 22:08:39.08

>>842
ただ集中型が求めるマネジメントは並の会社なら十分満足してる程度だけどな。
難易度/分量の見積もりが取れないようでは、査定/人員確保/納期見積もりも出来ないし。
gitはそれすら必要ないという意味では上だが、普通に会社として成立してる限り既に間に合ってる。
むしろ見積もりを取れない初心者(＝プログラミング経験3000時間以下)に有効なんだろうよ。

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

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

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

2023/08/20(日) 22:45:22.16

今のキミより新卒は優秀だから、gitにフィットしないのではとか気にしなくていいよ

2023/08/20(日) 23:02:34.62

これだけ長文連騰を続けてもそれに説得されて宗旨替えする人が出てこないことはこれまでの反応から
大体わわかっただろうがそれでもなんで続けているのか不思議に思ってた。
おそらくだが意固地になってgitを使わない自分自身を正当化したいだけなんだろうな。

2023/08/20(日) 23:19:10.98

長文君の理論だと Microsoft も Google も Apple も日本の大手各社も git メインで使ってるのでマネージメントできない給料泥棒ばかりだな。
きっとそいつらには理解できなくて優秀な長文君だけ理解できるんだろうな。さぞかし立派な成果出してるんだろうから紹介してくれ。

2023/08/20(日) 23:38:18.21

>>845
新人が編集した内容は初心者だろうがその新人が一番理解しているし、それを積み重ねる結果コードのすべてを把握できるような強いマネージャーはいなくなるので、なるべく誰にでもわかりやすい履歴が求められます。

2023/08/21(月) 07:46:21.21

>>847
そういうことだな
自分を正当化するために何とか言い返さなければならないということで言い返し続けた結果
gitに乗り換えるところは査定/人員確保/納期見積もりも出来ないし会社として成立していない
と主張することになってしまった
長文くんはどこまで行ってしまうのだろう

2023/08/21(月) 20:59:54.85

ちゃんとしたマネジメントがあれば分散開発のためのシステムは不要、っていうのは、
井戸に水を汲む係が居れば上水道なんかなくても困らない、っていう意見みたいなもんだぞ。
井戸水を汲む係が居て成立している組織のことを何も否定してないじゃない。
そんな係の担当になったり、係がいることによる不便を感じたりは嫌だから僕らはgitを使うよ、というだけで。
結局は好みで決まるものだと思うよ。

2023/08/22(火) 08:56:52.59

Git v2.42.0

2023/08/23(水) 07:41:56.03

個人ならどうぞ御勝手にだが、会社なら収益(＝効率)で使う使わないが決まる。
ツール(git)で補完される能力が既に足りてれば効果がなく、いわゆる日本の会社なら大体これに該当する。
だから「gitにしてから心も体も収益も絶好調でアットホームな職場です(目線)」なんて事にはならない。

2023/08/23(水) 07:50:50.23

これは各パーツの担当者達が好き勝手にブランチ生やして最終的にマージ要員の人がどれマージすりゃいいっすかー？と一人一人に確認しに行く流れかな
Gitってブランチの最終段階だけ取り込んでも道中の変更は反映されないのかな？使い方が悪い？

2023/08/23(水) 08:44:47.55

>>853
長文くんの主張は、会社として成立している集団はgitに移行しない
→gitに移行する集団は会社として成立していない
というものだっただろ >>843

gitに移行するのは変える必要がないのに手間隙かけてバージョン管理システムを
変えるバカな会社という主張に変えたのか?

2023/08/23(水) 09:46:21.13

他所の会社は分からないけど、分散型バージョン管理システムは最高な気がしている。
もっと良いものがあれば教えて欲しい。

2023/08/23(水) 10:32:52.47

結構有名な話だがGoogleはgitのような分散バージョン管理システムをメインには使っていない
会社の基盤に分散ファイルシステムがあるのでバージョン管理が分散システムである必要が無かった
一つのリポジトリに会社の全コードが格納されている
https://www.school.ctc-g.co.jp/columns/nakai2/nakai220.html

2023/08/23(水) 10:33:57.58

長文君は、
進捗管理するツール作るで→すでにGitHubであるだろ
わ、ワードならどうや？→すでにSharePointであるだろ
と指摘されたので、妬みで周りの邪魔する書き込み繰り返して自我を保ってるだけ

最低限バケツをこれ↓くらいに仕上げるまで書き込み自粛してほしいわ
https://developer.mamezou-tech.com/blogs/2023/03/28/github-projects-new-roadmaps-layout/

はやくしないとGitHub Desktopに実装されるかもしれんぞ？

2023/08/23(水) 10:36:44.05

>>857
何をもってメインというかは知らんが↓は？
https://github.com/google/mozc
そういやQt6対応するって宣言してからcommitされるまで早かったな

2023/08/23(水) 10:52:27.60

>>859
857の記事にも書いてあるようにOSS関連の一部プロダクトはGitも使ってるらしい

2023/08/23(水) 15:26:39.62

>>857
確かサービス等で使う作成したら即リリースするような開発での話だな。
google も android だの chrome だのサービスではなくプロダクト型の開発には git を使ってる。

2023/08/23(水) 22:46:27.46

>>855
>>843じゃなくて>>845だった

2023/08/24(木) 06:55:26.94

>>857
Piper/CitCがOSSまたはgoogleのサービスとして出てこないのは何故だろう？

2023/08/24(木) 14:29:24.75

>>863
https://gist.github.com/peketamin/08fc44a0e8bed1d2ba6d9d193f9ba86c
>結論としては...社内専用システムを用意したりする余裕のない組織、ガバナンスの弱い組織、強い技術リードが
>いない組織は、単一レポは難しそう...
ということで、OSS向きではないらしい

ただ近い運用ならmainオンリーで使い続けリリースはメンテナーが強権でcherry pickで取捨選択してリリースブランチ
作るなら出来そう。

2023/08/25(金) 00:31:50.60

OSSにしたところで、短時間で数百ものコミットを行うGoogleエリートプログラマのマネなんかできないだろ

2023/08/25(金) 05:00:12.06

>>863
技術的な話として
基盤となっているオーバーレイ型の共有ファイルシステムはコストフルなので速いネットワークを要求する
拠点内か高速のネットワークで拠点間を繋がなければ遅くて使えたもんじゃない
つまり google 内だから使える仕組みであって一般に使えるものじゃない
ファイルシステム自体が企業秘密だしね

2023/08/25(金) 05:22:43.53

>>864
レビュー・システム経由でしかコミットできない仕組みなので git で言うなら
・全員がローカルの master ブランチで開発する
・できたらコミット1回分ごとにプルリクを送ってレビューしてもらう
・レビュー通ったら本番サービスに即自動反映する
みたいな運用だな。WEBシステム特有というかサービス・プロバイダー特化

2023/08/25(金) 07:41:53.00

>>864
> 社内専用システムを用意したりする余裕のない組織
そういう会社こそ外部システムを必要とするわけだし、そいつは出来ない事にしたいだけだな。
モノリポが難しいわけではない。(むしろ簡単)
同様に分散が難しいわけでもない。(gitが無駄に難しく複雑なのは主に濱野がこの点では無能だからだろう)
なお、ソースコード履歴ツリーは、全く同じ運用がgitでも出来る。
(ただgitの推奨《＝みんながやってる形式》とは違うから、バグ踏む可能性もあるが)

>>866
そのままではCitcは無理なのは分かった。
ただ、ならgitと同様丸々コピーしてしまえば解決する。
世の中の全てを含んだモノリポではなく、関連する数個のリポの「マルチリポ」でも十分効果がある。

>>867
> WEBシステム特有というかサービス・プロバイダー特化
そうではないと思うがな。何故gitを使わないといけない事にしたいんだ？

gitは、Linus担当部分の「マージの効率化」が目的で、そこで発想が終了してる。
Piperは「アプリケーション開発全体の効率化」が目的で、当然「テスト」や「リファクタ」も含まれてる。
「依存関係」を見るには纏まってる方が便利だから、マルチリポ化を目指す事になる。
スケールメリットもあるので、速度に問題がなければ結果的にモノリポ化する。

何の開発でも「依存関係」の確認は必要だ。
結果的にマルチリポなら、mainリポ（＝本体)とsubリポ(＝依存関係を参照するだけ)に分離するだけで機能する。
googleって「ねえねえ僕ってすごいでしょ！！！入社してね！！！」みたいな方針のように見えるし、
社外にPiperモドキをリリースし、「続きはgoogleに入社してから！！！」な方が自然に感じる。

2023/08/25(金) 09:01:15.40

>>868
長文くんに理解できるように説明するのは難しそうだが、書いてみる
「世界中で動いているバージョンは一つだけ。古いのを動かすのは禁止。ベータ版みたいな未来のを動かすのは禁止。こうすることでバージョン違いによる整合性とかを考えなくて良くなる」
という割り切りをしたシステムだから。これは自社サーバーでのみプログラムを動かしてるから実現できる。
ユーザ側で動かすような android や chrome のような端末ソフトは複数バージョン並行で使われるので google でも git を使ってる

2023/08/25(金) 12:52:05.16

>>869
信者は所詮信者であり、会話は無理だと改めて理解した。
認識にバイアスがかかりまくってるのに気づけないからこその信者であり、定義通りだが。

2023/08/25(金) 14:24:47.15

具体的に書けないのは印象操作に見られても仕方ない

2023/08/25(金) 15:05:23.64

>>870
ならコメントするの止めろ。

あるいはコテハン付けろ。
NGするから。

2023/08/27(日) 14:35:48.07

>>870
信者の集まりで会話は無理だと思っているなら出てこなければいいのに
長文くんは鳥頭だからどうせまた出てくるんだろうな

2023/08/28(月) 17:00:34.15

それ以前にGitスレなのだからGit使ってる人しか来ないってことに、まだ気づかないのだろうか？

2023/08/28(月) 22:42:01.73

なんか他のブランチから引っ張って来ようとしたら競合が起きてチェリーピック出来ないんだけど、何が悪いんだろ？
あんまり見ずに時間切れになったからまた明日調べるつもり
存在しないものを削除しようとしてるとかあるのかな？

2023/08/28(月) 23:40:30.70

>>875
コンフリクトが起きるのは特に問題ないのでは？
コンフリクトではなくてコマンド自体が弾かれてるなら、worktree か index に変更中のファイルが残ってる可能性が大。
まずはそいつらをどうにかしてから cherry-pick してみたら

2023/08/29(火) 08:47:58.69

>>875
git stashで現状のソースを一時退避したあと、綺麗な状態にしてからcherry-pickして、stashの内容を復元したら？

2023/09/11(月) 13:00:51.18

>>875
存在してるものでも削除する

2023/09/11(月) 22:07:33.10

>>876-878
ありがとう、どうも更新の順番が逆だったみたいだ、お騒がせしました

2023/09/20(水) 15:05:17.00

TortoiseGitを使って、SVNのリポジトリをGitに変換してみたけど、
SVNとの併用が想定されているのか、タグがブランチのままだったり、
trunkという名前のブランチができていたり、思っていたのとちょっと違う結果でした。
完全一方向でよいのだけど、Windowsで綺麗に変換できるツールはありませんか？

2023/09/20(水) 23:39:58.91

>>880
ベースになるgit-svnがそういう変換動作だから仕方ないんじゃないの

2023/09/21(木) 02:20:33.87

>>880
svn と git は思想が違うので完全に一対一で移行するのはむずかしい。結局 svn をどういうルールで運用していて、それを git でどういう形に移行したいかは人によって違うので。
自分でスクリプト書いて移行しちゃうのが結局は楽だと思う。

2023/09/21(木) 08:55:56.61

>>881-882
trunk/branches/tagsのパターンで運用していたもの向けのスクリプトとか、
git-svnで変換したものに対する手動移行の方法とか、どこかで紹介されていませんかね

2023/09/21(木) 09:51:45.73

>>883
探せばいろいろ落ちてる気がするけど
探して検証してという手間を考えたら作った方が早い気がする（効果には個人差があります。あなたの燃費は異なるかもしれません。

2023/09/21(木) 10:22:17.06

こだわりあるみたいだし自分で調整するのが一番早いだろうね
ブランチ名変えるとかタグ付けてブランチ消すとか最低限覚えといて損しないコマンドだし
移行したいタグが大量にあったとしても、繰り返し処理とかプログラミングしなくたってアナクロなコピペ編集でコマンドを一杯こさえて一気に流せばよい
タグの一覧をコマンド等で出してそれをベースにVSCodeのマルチカーソルなりExcel関数なりなんならサクラエディタの置換なり
必要なコマンドを3つ4つ覚えればあとは30分あれば初めてでもできる

2023/09/21(木) 10:39:02.85

>>883
公式サイトにそれっぽいのがあったけどこれは見たの?
https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git
ちゃんと読んでないけどgit svn cloneからタグの話とtrunkブランチの話をしてるっぽく見えるよ?

2023/09/21(木) 11:17:57.92

>>886
このページはメニューから日本語にも切り替えられるので読んでみるといいよ
ただbashとかの操作に慣れてないときついかもしれん

2023/09/21(木) 18:31:50.78

>>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しかない気がする

2023/09/22(金) 12:25:38.45

>>884-888
みなさんありがとうございます。
TortoiseSVNやTortoiseGitやSourceTreeのGUIのみでやってきたので、
コマンドとかスクリプトとかが絡んでくると諦めそうになりますが、いろいろ試してみます。

2023/09/22(金) 14:07:04.05

>>889
最初はハードル高いけど、プログラマなら覚えてスクリプトとか書くようになると GUI まどろこしくてやってられねー。ってなるよ。
がんばれ

2023/09/30(土) 06:21:53.24

(*ノ・ω・）ノオオオオォォォォ

**デフォルトの名無しさん** (JP 0Hd1-tvb5) · 2023/09/30(土) 20:34:11.62

origin/branchとする場合と、origin branchとする場合が混在してて分かりにくいわ
設計がでたらめなんだろうな