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/17(木) 13:03:31.32

svn で共同開発したことがあったら、あんな嘘は書けないので、svn なんて全く知らなくて、git を叩きたいから良く知らない svn 持ち上げてるだけだろ

**デフォルトの名無しさん** (JP 0H7f-YOEV) · 2023/08/17(木) 15:50:32.76

長文くんはやたらとゴミバケツを無視しようとしてるけど「そのスレ立てたのは俺じゃない」とすら言わずに無視してるから，実質認めてるね

2023/08/17(木) 15:55:13.44

>>750
つまり「ひとり開発」ではその方法が最大効率だと自明なわけだ
そして「効率」だけを問題にするなら、実は多人数でも同様で、
各自ができるだけ干渉せず、別々にアップデートするだけの、「それぞれが『ひとり開発』状態」に持ち込むのが最大効率だ

これをアナログに目指すなら、綺麗にソースを分離し、各機能を追加/変更する際には別々のファイルに当たるようにすればいい
つまりJava方式も一つのやり方だよ
こういう事前準備を一切せず(出来ず)、デタラメな場合でも、
ブランチだマージだの力業で解決出来るようにした意味はあるが、(＝擬似的に「ひとり開発」状態に持ち込める)
元々無くても困らない(ように事前準備出来る)奴にとっては大した意味はないんだよ

2023/08/17(木) 17:46:25.25

>各自ができるだけ干渉せず、別々にアップデートするだけの、「それぞれが『ひとり開発』状態」に持ち込むのが最大効率だ

トピックブランチを切って各自がそれぞれ同時並行で作業を進めて最後にマージすることを言っているならわかるが。

2023/08/17(木) 18:05:43.87

バケツ君はCI知らないだけだな

2023/08/17(木) 19:39:17.59

1回でもちゃんとGit使ってみれば良いのに
普通に便利なツールだから皆使ってんのよ

2023/08/17(木) 20:52:34.50

少し前のスレ見てた人なら知ってるかもしれないけど、一応使ってなにかやろうとしてたよ
ただreflogを永続的な管理情報だと勘違いしたりとか、思い込みが激し過ぎて自分で修正できないタイプみたい

2023/08/17(木) 21:02:29.62

>>754
> トピックブランチを切って各自がそれぞれ同時並行で作業を進めて最後にマージすること
は
> (＝擬似的に「ひとり開発」状態に持ち込める)
と表現してる。

最大効率（＝余分な作業が一切ない)のは、
・一人で全部シリアルに変更した場合、とこれに準じた
・ブランチを切ってマージした場合に一切競合が無かった場合
だよ。だからブランチはマネジメントが行き届かない場合に効率の低下を防ぐ方策であって、
効率を上げる方策ではないし、十分にマネジメント出来てれば必要ない。
ゲーム開発連中はこれが分かってるからgit(というか君らによるとブランチなのか？)にメリットがないから移行しない。

ただgitのような分散型の場合、本質的にテスト効率が半分なので、
(つまり、ローカルリポジトリの作業でテストした後、マージ後にもう一度同じテストを流す必要がある)
集中型(masterに直接commitしていく場合も同じ)に比べて最終コード(により近い状態)でのテストの積み上がりが遅い。
連中が気にしてるのはこの辺かも。
(まあgitでも誰かしら本体にcommitしたら常にrebaseし直すルールで運用すれば同じにはなるが)

2023/08/17(木) 21:15:24.20

君らよくバケツくんの言ってることについていけるな
俺には彼が何を言いたいのかさっぱりわからん
そもそも必要もないカッコ書き多用するから読む気もしない
現場にいたら即切るレベルだよ

2023/08/18(金) 01:12:47.53

長文君は参考書斜め読みして理解できなくて、でも格好良い言葉使いたいので
意味も分からずに「マージ」だの「トピックブランチ」だのカタカナ用語言ってるだけなので、理解できないのは当然。
用語が矛盾だらけ。

2023/08/18(金) 04:37:22.20

CircleCI, Github Actions を知らないの？

Ruby on Rails で、知らなかったら就職できない

2023/08/18(金) 06:01:46.13

gitはlfsとかsubmoduleが後付けなのかしっくりしない感じがする。
クライアントの使い方を調べないと問題が解決出来ない事が多くてつれえわ。

2023/08/18(金) 09:14:49.70

gitなんてただの入れ物なのだから、それに過度にこだわるお前らは「名刺整理に精出してる営業」と同じだ。
名刺整理なんて必要な名刺がスパッと出てくれば何でもいい。
本来の問題はその先、顔/性格/要求事項等を思い出し、どう営業するかの算段を立てることだ。
名刺が出てきて満足してたら駄目だろ。

gitやsvnも同じで、過去のコードを確認したいときにスパッと出てくれば何でもいいんだよ。
本来はそのコードをどう改変して製品にしていくかであってね。
お前らは「ぼくのすごいせいりじゅつ！！！」で満足してるから、本来の問題が理解出来ない。

ゲーム会社なんて90年代(=git《2005》以前)からやってるところも多いし、
gitなんか使わずとも何とでもなるノウハウと経験を持ってる。
順当に考えて、お前らより技術も経験も能力も上だ。
その彼等が積極的に移行しないのは、単純に、メリットがないからだ。
gitを使えば全ての問題はたちどころに解決して幸せになれる！！！と信じて疑わないgit信者には理解出来ないとは思うが。

多分な、お前らはgitを使ってしかいないから、
使わなかったときに何が問題で、どういう解決方法があるかを知らないんだよ。
それで、「gitすごいんですよ！！！」と営業かけられても、「間に合ってます」でしかない。
解決済みの問題を「オレオレ流に解決したからこっち使え！！！」と言われてもウザイだけだろ。

AIによるコード生成にウキョウキョ言ってる連中の方がお前らより数万倍賢いと思うよ。
gitをいくらこねくり回しても、本質的な問題はどうにもならんだろ。
(まあこれがLinus曰く「最も興味がないものだと見なしていた」なのだろうけど。
ただまあ、読み返してみると、Linusのgitに対する見方は妥当だな。
少なくとお前らみたいにgitが普遍的に使える完成品だとは勘違いしてない。
https://ezoeryou.github.io/blog/article/2015-04-08-linus-git-interview.html)

2023/08/18(金) 11:38:09.76

バケツくん、元気にしていたんだね。
おじさん、心配していたんだよ。

2023/08/18(金) 14:52:19.84

自転車に乗れなかったやつが、人間ずっと昔から歩いてきてるんだから自転車に何か乗る必要はないってグダグダ説教してたのとそっくりで趣深い。
すっぱい葡萄ってやつか。

2023/08/18(金) 19:52:30.20

>>763
「過去のコードを確認したいときにスパッと出てくる」ソフトをつくると
言いながら全くつくれず、被害妄想を起こして逃げ出してそれきりの長文くんは
そう宣った

2023/08/18(金) 20:01:18.48

>>763

>多分な、お前らはgitを使ってしかいないから、

バージョン管理なしでクラウド同期ツールみたいなものだけ使うこともあるし、そもそもCVSもSubversionも使ったことあるがな

なぜ相手の経験を聞かずに勝手に決めつける？
まあ、「思い込んで勝手に決めつける」があんたの性格なんだろうけど。

2023/08/18(金) 21:06:11.08

>>767
だってお前らgit信者過ぎて話が色々おかしいじゃん。

無料でも使われないのは、使う価値/意味がないからだよ。
個人レベルだと面倒くさがってるだけの場合も多々あるが、
大企業なら調査チームも持ってるし、ガチで使う価値がないから使われてないだけ。
ここは認めた上で話を進めないと信者の与太話でしかない。
git使わない奴は頭がおかしいと思ってるお前らこそ頭がおかしい。

単純に、連中が今直面している問題をgitでは解決出来ないから使ってないだけ。
それ以上でも以下でもない。民間企業はお前らほど政治的でもないし。
で、その問題とは何ぞや？となるべき所が、
git使わないのはおかしい、としかならないお前らは信者過ぎてまともな議論は無理だ。
まあ知ってたけどさ。
gitに精出しすぎるとこうなるようだから、これからgit使う人は注意してねと。

で、もし、まだまともな議論をしてみたいという人がいるのなら、

・gitが解決した問題とは何なのか

について考えてみてくれ。
そして、単純に言えば、
ゲーム会社でそれは問題になってない(または既に別方法で解決している)から
彼等が積極的に移行することがないだけ。

2023/08/18(金) 21:27:26.27

長文くんは自分の中で都合よく見下せるように形作った「お前ら」に向けて話しているので、
実在の各位は反応しなければよろしい。反応したところで話は噛み合わない可能性が高い。
どうしても反応したければ彼用の隔離スレで頼む。
https://mevius.5ch.net/test/read.cgi/tech/1668901194/

2023/08/18(金) 21:47:01.87

そもそもなにがしたくて戻ってきたんだろう。
「git信者」を啓蒙するとか考えを改めさせようというなら無駄だから諦めろ。

2023/08/18(金) 22:06:30.36

>>770
お前含めた>>730-731の疑問に答えてるのに何言ってるんだ？
割とマジでお前ら頭悪すぎて話が追えないのな

2023/08/18(金) 22:08:09.77

>>770
長文くんはgitユーザーに嫌な思いをさせなければ気がすまないという
暗い情念で書き込んでるんだろ
前回は「過去のコードを確認したいときにスパッと出てくる」ソフトをつくると
うっかり言ってしまい、つくれずに被害妄想を起こして逃げ出すという醜態を
晒してしまったので今回はその話題を避けているようだから
長文くんが隔離スレに行くことはないだろう

2023/08/18(金) 22:09:56.25

おまえの妄想聞きたいわけじゃないから。

2023/08/18(金) 22:14:48.59

「無料でも使われない」
これ笑うところ？
すごく怖いんだけど。

2023/08/18(金) 22:20:06.58

都合悪い事を全部妄想だと言い出すのは末期症状だな

無料でこれほど有名なソフトを使わないのは、使う価値がないからだよ
これは俺がどうのこうの関係なく、極めて単純な事実だよ
これすら認めれない君らが適切に現状把握することはないだろうね

2023/08/18(金) 22:22:15.02

>>775
成仏してください……
南無阿弥陀仏南無阿弥陀仏

2023/08/18(金) 22:34:06.78

>>773
「俺の話を無視するのは俺の話がおまえらにとって都合が悪いからだ」
たしかに末期症状だね

2023/08/18(金) 23:06:26.85

>>768 >>775
乗り換えるのは手間暇がかかるし乗り換えの際にトラブルが起こる懸念もあるわけで
「無料でこれほど有名なソフトを使わないのは、使う価値がないから」
なんてことにはならないのに、それすら分からないのが長文くん
「バケツ」をつくると言ってたころよりバカになってるような

2023/08/18(金) 23:22:17.66

ソースの履歴管理やプロジェクト管理はGitHubで、WORDやEXCELの履歴管理はSharePoint(microsoft365)で
というのがMSの方針でなんの問題もないのだから乗り換えも起きんだろ。
　GitHubの履歴管理はマイルストーンや予実管理にも対応したからRedmineをも飲み込む勢いだし。
　強いてGitHubでOSS支援として足りんところは.svgzがまだ画像認識してないところとwikiのmarkdownが
mermaidに対応してないところくらい。

2023/08/19(土) 00:28:03.47

>>768
反論になってないだろ。
「gitしか使っていない」というから、CVSやSVNを使ったこともあるし、バージョン管理しないときもあると言っただけだ。
だから、もしそれでも「話が色々おかしい」と主張するならば、「gitしか使っていない」以外の理由を挙げなきゃだめだろ。明確に「gitしか使っていない」の反例を出してるんだから。

2023/08/19(土) 01:16:57.88

バーケーツ
バーケーツ

2023/08/19(土) 01:23:47.81

長文君には RCS の時代からバージョン管理使って来てるやつがいることとか思いもしないんだろうな。RCS → CVN → Subversion → git がメイン履歴だな。他にも浮気したけど
svn もかれこれ7年くらい使ってたわ

2023/08/19(土) 06:09:11.09

なんか症状悪化してんな
もう5ch止めた方が良いぞ。マジで

2023/08/19(土) 07:26:42.01

>>780
>>782
それが詭弁だと理解出来ないのはお前らの知能の問題だな。

>>779
> OSS支援として
ここがポイントだと俺は見てる。

Linusはバザール開発を発明した為、それまでの(伽藍開発しか想定してない)vcsでは対応出来ず、
バザール「専用」のgitを作った。
BitKeeper(分散リポジトリ)が解決したとされてる政治問題は、そもそも伽藍開発では最初から解決済みだし。
ただ、バザール専用といっても抽象基底がバザールってだけで
「一人バザール」(＝参加者が自分以外いないだけ)や
「10人バザール」(＝客が少ないだけ)等の派生もバザールではあり、結果的に伽藍でも使えるから蔓延った。
ただ、流用してるだけなので、伽藍で使うにはgitは無駄な手続きが多すぎてかなりまどろっこしいし、
伽藍でgitを使ったところで従来の(伽藍開発しか想定してない)vcsと比べて特にメリットもないから、
今後ともプロプライエタリ(≒伽藍)で開発していく連中が積極的に移行する事もない、といったところかと。

2023/08/19(土) 07:31:24.56

>>784
成仏してください……
南無阿弥陀仏南無阿弥陀仏

2023/08/19(土) 09:28:05.75

個人的な経験からバージョン管理の進歩で最大の進化を挙げていくと

rcs: バージョン管理で共同開発できる
cvs: リモートチェックアウトでロック取らずに共同作業可能になった
svn: アトミックコミットができるようになった
git: ローカルブランチが切れるようになった

というやつなので長文君の主張は全部的外れ
ローカルブランチのない時代には絶対に戻りたくない

2023/08/19(土) 11:03:42.68

>>786
gitならローカルだけの運用も可能だからね。
サーバー立てずに手軽に始められる。

2023/08/19(土) 12:17:06.17

>>784
まず「伽藍方式で開発しているところはgitに移行していない」というのが
事実だと示さなければどうしようもないことを理解できない長文くん

「バケツ」は伽藍方式向けなのかバザール方式向けなのか、どっち?

2023/08/19(土) 12:54:31.75

>>787には同意する。

>>786
> ローカルブランチ
これ言うほど意味あるか？
集中型でもローカルに動作環境を作って試す。
通常は最新版のファイルを全コピーし、目的のファイルだけ変更してテスト等流すことになる。
だから実際の作業状態は集中型でも分散型でも変わらない。
最終的に提出するのがファイルかリポジトリかという話であって。

2023/08/19(土) 13:06:42.80

バージョン管理使ったことないやつに同意されても困るわw

2023/08/19(土) 13:14:27.34

ローカルにブランチを作ってローカルにコミットを作ってローカルにコミットメッセージを仕上げて十分に確認する
ここまでの作業で気づいた間違いは自分以外の人に影響を与えることは全く無い
十分に確認して問題無いと判断出来たら、そのローカルブランチをそのまんまメインリポジトリのブランチにワンタッチで昇格できる
これが実務を安らかに遂行する上でどれだけ助けになるか、自分の妄想を垂れ流すだけの恥知らずにはわからんのだろうな

2023/08/19(土) 13:14:28.60

インストールは一人でもできるから同意出来るさー。

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に乗り換えるところは査定/人員確保/納期見積もりも出来ないし会社として成立していない
と主張することになってしまった
長文くんはどこまで行ってしまうのだろう