Git 19

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん (ﾜｯﾁｮｲ 8be4-Cw2/)
垢版 |
2022/11/06(日) 16:40:27.51ID:az1H5JFk0
ソースコード管理を行う分散型バージョン管理システム、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/16(水) 09:18:06.02ID:shyXhCG/0
>>735
使う必要がないと分からないのはお前の問題
738デフォルトの名無しさん (ﾜｯﾁｮｲ 4ecf-eQmn)
垢版 |
2023/08/16(水) 09:28:54.97ID:x0p4Dvkt0
>>734
なんとかバケツの方はどうなったのよ?
とりあえず作ってあるとこまで仕様のテキストでもコードでもあるものリポジトリで公開してみてよ
みんなで見よう
2023/08/16(水) 09:34:15.84ID:shyXhCG/0
ああそういえばsvnもブランチは切れるぞ
ただ集中型だから各ディレクトリになり、gitとは形式が異なるが、それ用に環境作ってあれば何ら問題ない
だからブランチが使えるだけでgitに移行する理由にはならないし、そう思えるのなら見識が狭すぎる
2023/08/16(水) 11:44:03.25ID:G7CQiFLH0
色々理由はあると思うけど、
- アセットなどのバイナリファイル主体だからいちいちブランチを切り替える意味があまりない
- ファイルのロックが簡単
- 非プログラマでもgitよりは扱いやすい
だいたいこの辺りじゃね？

バケツ野郎じゃないけど、何でもかんでもgitでやればいいと言うのはどうかと思うぞ
2023/08/16(水) 20:42:47.86ID:jMAEN3UU0
アーティストはコマンド直接は使わんし管理ツール作り直すのもめんどいし
2023/08/17(木) 02:13:40.06ID:/c9h87BG0
>>739
ブランチ切れるかどうかなんて問題にしてないよ
ブランチをどのように活用できるかの問題
お前まともに git 使ったことないだろ
2023/08/17(木) 08:31:55.84ID:zl6mWfwu0
>>742
gitを使えば全てが解決して幸せになれると信じるgit統一教信者乙

そりゃお前がsvnのブランチモデルを活用出来ないだけ
git使うだけでリリースが1ヶ月早められるのなら、みんなgit使ってるよ
連中にとってメリットがないからgitを使わないだけという事実をきちんと受け止めた方がいい

そもそも俺はブランチで効率が上がるのはマネジメント不足なだけで本末転倒だとも思うが
(巻き戻し《≒ブランチの破棄》が行われない限りブランチで効率が上がることはないと思ってる
逆に言えばマネジメントがまともに出来ないレベルの連中でもそこそこの開発効率を得られる点ではブランチは有効だが、
会社の場合は既に有能か無能か分かってる連中に仕事を配分するから、そこまで酷くなることはない)

伝わらないかもしれないが、「最終的に『必ず』マージすると分かっている作業なら、
最初からマージした状態で作業を進めていった方が理論的な効率は高い」ということ
つまり、形式としてはsvnの方がgitより理論効率は高いことになる
(実際に出来るかどうかはまた別だが)

多分な、(オープンソース等)ある程度rejectする前提ならgitのように気軽にブランチ丸ごと捨てられる構造が便利だが、
(プロプライエタリ等)最終的に全員のコードをマージする前提で仕事配分してたら、svnでも、ブランチ無くても、大して問題ないって事だと思う
2023/08/17(木) 08:43:35.27ID:/c9h87BG0
>>743
git 使ったことないのが丸わかりの意見でw
2023/08/17(木) 09:43:17.45ID:ri4IcwiZ0
>最初からマージした状態で作業を進めていった方が理論的な効率は高い」ということ

同じファイルを触ってたらわけわかんなくなるな。
その場合VSSみたいにファイル単位でロックする仕組みが必要かな。
746デフォルトの名無しさん (ﾜﾝﾄﾝｷﾝ MM17-epl3)
垢版 |
2023/08/17(木) 10:28:22.80ID:O9IbbVomM
>>743
このスレ立てた人だよね?

日常の進捗履歴記録ツールWitBucket(仮称)検討中
https://mevius.5ch.net/test/read.cgi/tech/1668901194/

否定しないなら同じ人って判断するけど、とりえあず顛末だけでも書かないとここで何言っても
他の人からは「投げっぱなしのテキトーな人」って目で見られて誰も聞く耳持ってくれないと思うよ?
2023/08/17(木) 10:29:50.40ID:40tRnXUX0
みんな分かってるから触れなくていいっての
マジで
2023/08/17(木) 12:11:03.75ID:zl6mWfwu0
>>745
> 同じファイルを触ってたらわけわかんなくなるな。
その通りだが、それがどれだけあるかという話なのと、アナログに回避出来るという事。

理解してくれてると思うが、俺が言ってるのは、最終的にFast-Forwardマージしていくのなら、
最初からそのラインを辿るように変更していくのが最大効率だということ。
そしてこれは難しいことでもない。会社で仕事を差配する側なら当然全員出来る。
(逆に言えば、ブランチはまともなマネジメントが出来ないレベルでも何とかなるようにした。
だからある意味初心者ほどブランチの恩恵にあやかれる。多分git信者がブランチにこだわるのはこれ)

同一ファイルを同時に変更するにはブランチが必要だが、これは単純に、
・同時には変更せず、シリアルに変更する。
　だってgitでマージしたら結果的に見た目はそうなるのだし、絶対に「同時に」変更する必要があるわけではない。
・そもそも「仕事」で配分してる会社ってあるのか？
　Javaのように1クラス1ファイルのように小分けしてて「担当モジュール」制度なら自動的にシリアル化する。
・「仕事」＝「仕様変更/追加」単位で仕事を配分し、全員がどのファイルをどう変更してもいい、最適な箇所を自由に変更しろ
　というのは理想的ではあるが、実際は出来ないと思う。
　よく知りもしないファイル/モジュールを変更するとバグる(または、潜在バグを埋め込む)ものだから。

担当モジュール制は、実際の所、より非力なチームでも通用する方法であって、
(プロプライエタリまたは少人数等で)実力をお互いに把握出来てる状態ならこれが完全に機能する。(からほぼ全社このシステムのはず)
だからsvnでもブランチ無くても関係ないんだと思うぜ。
(まあgitでも問題ないが、現時点で問題なく機能してるsvnから移行する理由がない)
gitはこの辺linuxに全振りだから、linuxには最適だが、それ以外には大してメリットもない。

ちなみにsvnのブランチなら、他人の作業状態もそれなりに見える。だから遅れてる部分も丸見えではある。
gitの場合は完成品を納品するシステムだから、遅れてる奴が黙ってたら全く検知出来ない。
勿論この辺はgitではなく上位戦略で回避すべき案件ではあるが、実際に問題になることもあるとは思う。
2023/08/17(木) 12:18:48.57ID:oGbYN+EC0
gitを分かってないから、svnの優位点語るのに頓珍漢なことしか言えないんだろうな
svnも分かってるかどうか(実際の現場でどのように使われるかに関して)も怪しい
2023/08/17(木) 12:52:59.75ID:ri4IcwiZ0
ようはトピックブランチを使わずにmasterに直接commit/pushするようなやり方だろ。
ひとり開発でならよくやるな。
2023/08/17(木) 13:03:31.32ID:d5O4VVsaM
svn で共同開発したことがあったら、あんな嘘は書けないので、svn なんて全く知らなくて、git を叩きたいから良く知らない svn 持ち上げてるだけだろ
2023/08/17(木) 15:50:32.76ID:BJu8USc1H
長文くんはやたらとゴミバケツを無視しようとしてるけど「そのスレ立てたのは俺じゃない」とすら言わずに無視してるから，実質認めてるね
2023/08/17(木) 15:55:13.44ID:zl6mWfwu0
>>750
つまり「ひとり開発」ではその方法が最大効率だと自明なわけだ
そして「効率」だけを問題にするなら、実は多人数でも同様で、
各自ができるだけ干渉せず、別々にアップデートするだけの、「それぞれが『ひとり開発』状態」に持ち込むのが最大効率だ

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

トピックブランチを切って各自がそれぞれ同時並行で作業を進めて最後にマージすることを言っているならわかるが。
2023/08/17(木) 18:05:43.87ID:H7X3UE9D0
バケツ君はCI知らないだけだな
2023/08/17(木) 19:39:17.59ID:Fh9vwJEA0
1回でもちゃんとGit使ってみれば良いのに
普通に便利なツールだから皆使ってんのよ
2023/08/17(木) 20:52:34.50ID:LN2mo1dt0
少し前のスレ見てた人なら知ってるかもしれないけど、一応使ってなにかやろうとしてたよ
ただreflogを永続的な管理情報だと勘違いしたりとか、思い込みが激し過ぎて自分で修正できないタイプみたい
2023/08/17(木) 21:02:29.62ID:zl6mWfwu0
>>754
> トピックブランチを切って各自がそれぞれ同時並行で作業を進めて最後にマージすること
は
> (＝擬似的に「ひとり開発」状態に持ち込める)
と表現してる。

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

ただgitのような分散型の場合、本質的にテスト効率が半分なので、
(つまり、ローカルリポジトリの作業でテストした後、マージ後にもう一度同じテストを流す必要がある)
集中型(masterに直接commitしていく場合も同じ)に比べて最終コード(により近い状態)でのテストの積み上がりが遅い。
連中が気にしてるのはこの辺かも。
(まあgitでも誰かしら本体にcommitしたら常にrebaseし直すルールで運用すれば同じにはなるが)
2023/08/17(木) 21:15:24.20ID:oGbYN+EC0
君らよくバケツくんの言ってることについていけるな
俺には彼が何を言いたいのかさっぱりわからん
そもそも必要もないカッコ書き多用するから読む気もしない
現場にいたら即切るレベルだよ
2023/08/18(金) 01:12:47.53ID:mGP0mIml0
長文君は参考書斜め読みして理解できなくて、でも格好良い言葉使いたいので
意味も分からずに「マージ」だの「トピックブランチ」だのカタカナ用語言ってるだけなので、理解できないのは当然。
用語が矛盾だらけ。
2023/08/18(金) 04:37:22.20ID:pbc8FSyxa
CircleCI, Github Actions を知らないの？

Ruby on Rails で、知らなかったら就職できない
2023/08/18(金) 06:01:46.13ID:0N1EMKz10
gitはlfsとかsubmoduleが後付けなのかしっくりしない感じがする。
クライアントの使い方を調べないと問題が解決出来ない事が多くてつれえわ。
2023/08/18(金) 09:14:49.70ID:DqVFTH2M0
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.76ID:P2hKBqqY0
バケツくん、元気にしていたんだね。
おじさん、心配していたんだよ。
2023/08/18(金) 14:52:19.84ID:mGP0mIml0
自転車に乗れなかったやつが、人間ずっと昔から歩いてきてるんだから自転車に何か乗る必要はないってグダグダ説教してたのとそっくりで趣深い。
すっぱい葡萄ってやつか。
2023/08/18(金) 19:52:30.20ID:3u957UtZ0
>>763
「過去のコードを確認したいときにスパッと出てくる」ソフトをつくると
言いながら全くつくれず、被害妄想を起こして逃げ出してそれきりの長文くんは
そう宣った
767デフォルトの名無しさん (ﾜｯﾁｮｲ 3e2d-QSj3)
垢版 |
2023/08/18(金) 20:01:18.48ID:Nyuhq8Qv0
>>763

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

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

なぜ相手の経験を聞かずに勝手に決めつける？
まあ、「思い込んで勝手に決めつける」があんたの性格なんだろうけど。
2023/08/18(金) 21:06:11.08ID:DqVFTH2M0
>>767
だってお前らgit信者過ぎて話が色々おかしいじゃん。

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

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


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

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

について考えてみてくれ。
そして、単純に言えば、
ゲーム会社でそれは問題になってない(または既に別方法で解決している)から
彼等が積極的に移行することがないだけ。
2023/08/18(金) 21:27:26.27ID:V3qpbLuH0
長文くんは自分の中で都合よく見下せるように形作った「お前ら」に向けて話しているので、
実在の各位は反応しなければよろしい。反応したところで話は噛み合わない可能性が高い。
どうしても反応したければ彼用の隔離スレで頼む。
https://mevius.5ch.net/test/read.cgi/tech/1668901194/
2023/08/18(金) 21:47:01.87ID:oKkzIZWd0
そもそもなにがしたくて戻ってきたんだろう。
「git信者」を啓蒙するとか考えを改めさせようというなら無駄だから諦めろ。
2023/08/18(金) 22:06:30.36ID:DqVFTH2M0
>>770
お前含めた>>730-731の疑問に答えてるのに何言ってるんだ？
割とマジでお前ら頭悪すぎて話が追えないのな
2023/08/18(金) 22:08:09.77ID:3u957UtZ0
>>770
長文くんはgitユーザーに嫌な思いをさせなければ気がすまないという
暗い情念で書き込んでるんだろ
前回は「過去のコードを確認したいときにスパッと出てくる」ソフトをつくると
うっかり言ってしまい、つくれずに被害妄想を起こして逃げ出すという醜態を
晒してしまったので今回はその話題を避けているようだから
長文くんが隔離スレに行くことはないだろう
2023/08/18(金) 22:09:56.25ID:oKkzIZWd0
おまえの妄想聞きたいわけじゃないから。
2023/08/18(金) 22:14:48.59ID:pJm/stU2M
「無料でも使われない」
これ笑うところ？
すごく怖いんだけど。
2023/08/18(金) 22:20:06.58ID:DqVFTH2M0
都合悪い事を全部妄想だと言い出すのは末期症状だな

無料でこれほど有名なソフトを使わないのは、使う価値がないからだよ
これは俺がどうのこうの関係なく、極めて単純な事実だよ
これすら認めれない君らが適切に現状把握することはないだろうね
2023/08/18(金) 22:22:15.02ID:hfXr0Ior0
>>775
成仏してください……
南無阿弥陀仏南無阿弥陀仏
2023/08/18(金) 22:34:06.78ID:oKkzIZWd0
>>773
「俺の話を無視するのは俺の話がおまえらにとって都合が悪いからだ」
たしかに末期症状だね
2023/08/18(金) 23:06:26.85ID:3u957UtZ0
>>768 >>775
乗り換えるのは手間暇がかかるし乗り換えの際にトラブルが起こる懸念もあるわけで
「無料でこれほど有名なソフトを使わないのは、使う価値がないから」
なんてことにはならないのに、それすら分からないのが長文くん
「バケツ」をつくると言ってたころよりバカになってるような
2023/08/18(金) 23:22:17.66ID:jrXTaCKp0
ソースの履歴管理やプロジェクト管理はGitHubで、WORDやEXCELの履歴管理はSharePoint(microsoft365)で
というのがMSの方針でなんの問題もないのだから乗り換えも起きんだろ。
　GitHubの履歴管理はマイルストーンや予実管理にも対応したからRedmineをも飲み込む勢いだし。
　強いてGitHubでOSS支援として足りんところは.svgzがまだ画像認識してないところとwikiのmarkdownが
mermaidに対応してないところくらい。
780デフォルトの名無しさん (ﾌﾞｰｲﾓ MM85-z8Bp)
垢版 |
2023/08/19(土) 00:28:03.47ID:XhvWl0BqM
>>768
反論になってないだろ。
「gitしか使っていない」というから、CVSやSVNを使ったこともあるし、バージョン管理しないときもあると言っただけだ。
だから、もしそれでも「話が色々おかしい」と主張するならば、「gitしか使っていない」以外の理由を挙げなきゃだめだろ。明確に「gitしか使っていない」の反例を出してるんだから。
781デフォルトの名無しさん (ｱｳｱｳｱｰ Sa6b-1fKg)
垢版 |
2023/08/19(土) 01:16:57.88ID:MO3fZl0Ca
バーケーツ
バーケーツ
2023/08/19(土) 01:23:47.81ID:Af/nXbF+0
長文君には RCS の時代からバージョン管理使って来てるやつがいることとか思いもしないんだろうな。RCS → CVN → Subversion → git がメイン履歴だな。他にも浮気したけど
svn もかれこれ7年くらい使ってたわ
2023/08/19(土) 06:09:11.09ID:JpdK29XE0
なんか症状悪化してんな
もう5ch止めた方が良いぞ。マジで
2023/08/19(土) 07:26:42.01ID:2LFpxJcr0
>>780
>>782
それが詭弁だと理解出来ないのはお前らの知能の問題だな。


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

Linusはバザール開発を発明した為、それまでの(伽藍開発しか想定してない)vcsでは対応出来ず、
バザール「専用」のgitを作った。
BitKeeper(分散リポジトリ)が解決したとされてる政治問題は、そもそも伽藍開発では最初から解決済みだし。
ただ、バザール専用といっても抽象基底がバザールってだけで
「一人バザール」(＝参加者が自分以外いないだけ)や
「10人バザール」(＝客が少ないだけ)等の派生もバザールではあり、結果的に伽藍でも使えるから蔓延った。
ただ、流用してるだけなので、伽藍で使うにはgitは無駄な手続きが多すぎてかなりまどろっこしいし、
伽藍でgitを使ったところで従来の(伽藍開発しか想定してない)vcsと比べて特にメリットもないから、
今後ともプロプライエタリ(≒伽藍)で開発していく連中が積極的に移行する事もない、といったところかと。
2023/08/19(土) 07:31:24.56ID:JNxKk40N0
>>784
成仏してください……
南無阿弥陀仏南無阿弥陀仏
2023/08/19(土) 09:28:05.75ID:Af/nXbF+0
個人的な経験からバージョン管理の進歩で最大の進化を挙げていくと

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

というやつなので長文君の主張は全部的外れ
ローカルブランチのない時代には絶対に戻りたくない
2023/08/19(土) 11:03:42.68ID:5NZcE5rk0
>>786
gitならローカルだけの運用も可能だからね。
サーバー立てずに手軽に始められる。
2023/08/19(土) 12:17:06.17ID:WQ8pf8iV0
>>784
まず「伽藍方式で開発しているところはgitに移行していない」というのが
事実だと示さなければどうしようもないことを理解できない長文くん

「バケツ」は伽藍方式向けなのかバザール方式向けなのか、どっち?
2023/08/19(土) 12:54:31.75ID:2LFpxJcr0
>>787には同意する。

>>786
> ローカルブランチ
これ言うほど意味あるか？
集中型でもローカルに動作環境を作って試す。
通常は最新版のファイルを全コピーし、目的のファイルだけ変更してテスト等流すことになる。
だから実際の作業状態は集中型でも分散型でも変わらない。
最終的に提出するのがファイルかリポジトリかという話であって。
2023/08/19(土) 13:06:42.80ID:QQmUr01P0
バージョン管理使ったことないやつに同意されても困るわw
2023/08/19(土) 13:14:27.34ID:vl4t9mIK0
ローカルにブランチを作ってローカルにコミットを作ってローカルにコミットメッセージを仕上げて十分に確認する
ここまでの作業で気づいた間違いは自分以外の人に影響を与えることは全く無い
十分に確認して問題無いと判断出来たら、そのローカルブランチをそのまんまメインリポジトリのブランチにワンタッチで昇格できる
これが実務を安らかに遂行する上でどれだけ助けになるか、自分の妄想を垂れ流すだけの恥知らずにはわからんのだろうな
2023/08/19(土) 13:14:28.60ID:7gpnkKpM0
インストールは一人でもできるから同意出来るさー。
2023/08/19(土) 13:51:27.18ID:2LFpxJcr0
>>791
> ここまでの作業で気づいた間違いは自分以外の人に影響を与えることは全く無い
それはどんな環境でも同じだよ。
違いは提出物がファイルかリポジトリかで、一つのファイルしか触ってないのならファイル提出の方が断然楽だ。

しかもお前ら、
> そのローカルブランチをそのまんまメインリポジトリのブランチにワンタッチで昇格できる
は禁止なんだろ？
仮にパッチを作成するのに10日間かかったとして、
1日目(○○やります！！！)、2日目、、、10日目(完成しました！！！)、というコミットではなく、
最終的にrebaseして一発で最終状態(10日目の結果)を生成したと改竄した履歴をローカルリポジトリに作り、それを提出しろ、と言うんだろ。
なら意味ねーじゃん。
2023/08/19(土) 14:20:20.06ID:JpdK29XE0
いいから一度ちゃんとGit使えって
もう業界のデファクトスタンダードなんだって
お前めっちゃ恥ずかしい発言を連発してんだぞ
2023/08/19(土) 14:41:38.83ID:Af/nXbF+0
>>789
プログラム書けないやつはこれだから……

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

まだまだ書けるけど？
2023/08/19(土) 15:09:35.75ID:WQ8pf8iV0
長文くんは試行錯誤なんてできないからな
「バケツ」のときも、つくるのなら試行錯誤するしかないから
そうしろと言われたら「迫害された」と叫んで逃げ出したし
2023/08/19(土) 15:12:04.16ID:vl4t9mIK0
>>793
おまえは勘違いしているというか、gitのブランチとリポジトリを理解できてない
「ローカルブランチをそのまんまメインリポジトリのブランチにワンタッチで昇格」これを禁止してるところはほとんど無い
プルリクエストで管理者がチェックしてメインブランチにマージする現場でも、まずはローカルブランチをメインのリポジトリにpushしてチェックしてもらうんだから
2023/08/19(土) 15:21:01.19ID:vl4t9mIK0
>>793
提出物がファイルではなくてソース環境のほぼ完全なスナップショットであるブランチなのが重要なのだよ
それを誰への影響もないローカルなリポジトリで作って他人が閲覧可能なリモートへ簡単に昇格できる
svnは途中から近いことができるようになったがcvs以前では考えられないような便利な仕組み
2023/08/19(土) 15:41:12.22ID:Af/nXbF+0
>>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.73ID:2LFpxJcr0
>>795
それ全部、ブランチ無くてもローカルでコピーすれば出来る案件だろ。
実際、git以前でも出来たけど、何故出来ないと思ってるの？
お前、共有リポジトリを生でいじるガイジか？

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



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

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

逆にHgとかはこの「ぐちゃぐちゃ」な履歴を保持するポリシーなのかな？
あちらは履歴の改竄は禁止だと聞いているので。
誰か知ってたら教えて。
2023/08/19(土) 16:53:04.38ID:ndraJbkl0
>それ全部、ブランチ無くてもローカルでコピーすれば出来る案件だろ。

だから何だというんだろう。ブランチ使わずにできるからコピーで頑張りましょうってか？
2023/08/19(土) 17:16:31.29ID:Af/nXbF+0
>>800
ちゃんと調べたか？
git も hg も同じだよ。そのためのローカルブランチなんだから
どっちも共有リポジトリの改竄は禁止、やったやつは腹を切れ。ローカルはお前にしか影響ないんだから好きにしろ。
2023/08/19(土) 17:25:39.06ID:Af/nXbF+0
> お前にとって残したい履歴は何？という話)

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

タイポの修正履歴とかは他の人にとってはノイズでしかないので共有不要。自分の手元にだけ残っていれば良い。タイポ修正前のコードを見たいやつはいない。
多人数で開発する場合はノイズが少ないほど開発効率が上がるしバグも少なくなる。
2023/08/19(土) 17:58:00.64ID:0srhzwdMM
>>800
最終成果物としてマージする目的のブランチの他にも、まだ作業中で整理していないブランチもメインリポジトリで共有するぞ

作業方針をレビューする目的とか、お前みたいに口ばっかで全然作業が進まないやつをキツめにフォローする目的とかでな
2023/08/19(土) 21:34:40.48ID:2LFpxJcr0
>>802
いや調べてない。以下読んだだけ。
> Mercurialは「履歴は永久的で神聖である」という哲学を持っていて、
> 履歴を操作するコマンドとしては1種類しかありません。
> その一方で、Gitは履歴を操作できる範囲が広いという違いがあります。
> https://tracpath.com/works/development/git-mercurial-subversion/
だから、多分、君らが思ってるほど同じじゃないんだよ。gitは履歴改竄する前提だ。

> どっちも共有リポジトリの改竄は禁止、やったやつは腹を切れ。ローカルはお前にしか影響ないんだから好きにしろ。
これは当たり前で、俺が言ってるのはこれではなく、
「ぐちゃぐちゃ」の履歴を保持する文化があるか、ということ。次レス以降参照
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する機構が足りてないのを誤魔化してるだけ。
それで騙されてるお前らはお花畑過ぎる。
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を理解出来ないから移行出来ないのだ！とかいう、
「上から目線ガー」とかうるさい割には心の中では心底他人を馬鹿にしてるゆとりマインドでは理解不能かもしれんが)
2023/08/19(土) 21:45:36.49ID:QQmUr01P0
コミットが開発プロセスの資産であることを本質的にわかってないんだろうね
うちのプロジェクトのメンバーにもそういう人がいるんだよね
毎回説明しても理解してくれない…
2023/08/19(土) 22:22:25.04ID:2LFpxJcr0
>>808
コードが資産で、コミットやgitでの管理は手段だよ。
それは典型的な手段の目的化であり、お前が間違ってる。

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

と毎回説明しても理解してくれない…とそいつも思ってるだろうよ。
2023/08/19(土) 22:41:56.92ID:ndraJbkl0
>ユーザーが求めてるのは、新規機能の実装やバグの修正であって、

gitを使ってそれができているならなんの問題もないわけだがあんたはいったいなにを主張したいんだろうか
2023/08/19(土) 22:55:00.77ID:Af/nXbF+0
>>806

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

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

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

お前の脳内結論とか持ってこられても開発効率は上がらないんだよ。複雑なバグの追跡やコードの再利用には綺麗な履歴が必須。
2023/08/19(土) 22:57:43.95ID:QQmUr01P0
>>809
なんで資産かどうかの話にユーザが出てくるんだよ
もしかして資産は全てユーザに公開されるものだと思ってる？プロダクトの話ではなくて開発プロセスの資産の話だぞ
2023/08/19(土) 23:16:41.01ID:vl4t9mIK0
>>807
みんなは知ってる
でもお前は知らなかった
複数履歴に跨るようなgrepもできるのをお前はしらない
知らないのはおまえだけ
2023/08/19(土) 23:17:28.06ID:Af/nXbF+0
>>807
svn 使ったことないのに、知ってる風を装って語るので嘘杉て笑いが止まらない。
push する前に同期が必要なのが git
commit する前に同期が必要なのが svn
理解できるかな？ 無理だろうな。
2023/08/19(土) 23:19:47.05ID:vl4t9mIK0
>>807
作業中のブランチをレビューするのにメインリポジトリで共有するのはそれが簡単だから
レビューするのに最新の状態との同期とか必用無いし
作業前の状態との比較も簡単にできるし
そのままで問題なさそうなら最終成果物としてマージできるように同期して調整するのも簡単
必要無くなったら消すのも簡単
お前の妄想する手間がかかるから無駄とかこの機能を使わない理由のなんの説明にもなっていない
お前は理解できてないから手間がかかるとか無駄とか妄想を垂れ流す
2023/08/19(土) 23:21:47.54ID:vl4t9mIK0
>>814
いやgitはpushする前に同期は必須ではない
同期が必要な場合と必要でない場合を理解できて一人前
2023/08/19(土) 23:38:08.78ID:Af/nXbF+0
>>816
ごめん。何を言ってるのか分からない。まさか push -f しろと主張してるの？
2023/08/19(土) 23:43:08.38ID:vl4t9mIK0
>>817
オレが多分話の流れを読んで無いだけだと思うけど、push前に同期が必須かと問われたら
、同期が必須なのは他人がpushする可能性があるブランチだけと答える
2023/08/19(土) 23:51:47.78ID:Af/nXbF+0
>>818
なら単に用語の問題だな
git の push はブランチ単位での同期を要求する。push するブランチの同期が取れてるなら当然それ以上同期コマンドを実行する必要はない。
svn の commit はチェックアウトした範囲全体の同期を要求する。リポジトリ全体をチェックアウトしたなら全体の同期が必要。

まあどっちもとりあえずやってみて、失敗したら同期コマンド打てば良いだけだけどな
2023/08/20(日) 00:58:08.93ID:Vn08TQPe0
>>813
では何故改竄された綺麗な履歴を欲しがる？
俺なら799の場合は

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

として実際の履歴で登録し、
masterにFFマージでこのドタバタ履歴が全部繋がってもgrepですっ飛ばせるのだから問題ないよね、
としたいが、実際はこれが出来ないから手動で改竄した綺麗な履歴を欲しがっているのではないのか？
2023/08/20(日) 01:06:37.87ID:vNIwX77X0
>>820
じゃあ、ゴミログ残して、お前このあと C は必要だが A は別の機会にってなったときに簡単に対応できるか？
後から他人のゴミログ追いかけて必要な部分と不要な部分切り分ける手間暇馬鹿にならないし、ミスする確率も増える
2023/08/20(日) 01:49:04.21ID:st7HSyAz0
>>820
綺麗な履歴とお前の言うgrepが関係あるといのは、お前の思いこみ妄想

綺麗な履歴を作らないようなプロジェクトもたくさんある
2023/08/20(日) 04:04:05.06ID:Qj2YxZj80
長文くんの考えは全部捨てずに突っ込んでおけば必要なものは探し出せるはずで
整理整頓なんか不要だし見た目が悪くても気にしないしそれで他の人が困ろうとどうでもいい
というゴミ屋敷理論だからなあ
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の忖度で「マネジメントも僕の修正も完璧、イエーイ、パチパチパチ」と小綺麗に改竄された履歴からでは、何も改善出来ない。
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の「清書」を作成だ。これが最大効率だ。
高い確率で必要ない「清書」を毎回ご丁寧にやる意味はない。
2023/08/20(日) 08:44:51.44ID:fiK4YkusM
マージ側に都合がいいというのは正しいかもね。日頃からその視点を持って作業したら。
2023/08/20(日) 08:56:28.01ID:vNIwX77X0
>>824
だから git 使えば清書は 10秒でできる。
2時間かけるのは馬鹿らしいって話。
2023/08/20(日) 08:58:29.28ID:rPtHvv2SM
長文さんは共同開発プロジェクトにgit使ったこと無いんじゃないかな。
むか〜しに共同開発プロジェクトに参画させてもらった記憶だけで長文書いてそう。
こんなごちゃごちゃ口だけやかましい奴はプロジェクト推進の邪魔だから当時退場させられたんだろう多分
2023/08/20(日) 09:56:03.93ID:DNMNb0+B0
現実を見ていない妄想まみれのレスは置いといて、gitで清書したコミットだけをpushする方法ってあるのかしらん？

ずいぶん前の話なので今は挙動違うかもしれんが、書き散らかした十数のコミットがあってマージでひとつにまとめたとき、まとめた方のコミットだけpushしようとしても十数のコミットもおまけにpushされる。
このおまけのpushを避ける方法てあるのかしらん？
2023/08/20(日) 10:16:43.69ID:eWjoENHw0
cherry-pick
2023/08/20(日) 10:17:14.38ID:Vn08TQPe0
>>826
だからgitはマージ専用機であり、gitを使えばマージの効率は上がる。
ただそれは多数側のコード書いてる担当者に負担を押しつけた結果だから、アプリケーション全体の開発効率は下がる。

ってのがgitの問題点だろうよ。
(しかもこれは意図的な仕様だ)
2023/08/20(日) 10:35:23.52ID:vNIwX77X0
>>829
多分、すごい古い git を使ってたんじゃないかな？
最近のはデフォルトが変更されていて、現在のブランチだけが push されるので他のものは push されないよ （オプションか設定変更で変えれる）
2023/08/20(日) 10:38:38.99ID:vNIwX77X0
>>831
開発効率が下がるのは清書に2時間かけちゃう、お前だけだろ？
2023/08/20(日) 10:54:29.71ID:P3ytobrG0
>それをせずに後付でAはやっぱり止めろ、と言うのはマネジメントの失敗であり、

前にもうまくマネジメントすればブランチは不要てなことを書いていたと思うが
それをやるのにかかるコストのことは考えてるんかね。
2023/08/20(日) 11:07:43.43ID:fiK4YkusM
完璧な計画が作れないのはバケツであなたが体験した通りですよ
2023/08/20(日) 12:15:53.56ID:lyAuLRyDM
他人が10秒でやる仕事に2時間かけるのは無能
無能を棚に上げて、マネージメントのせいにして仕事拒否するとか、馬鹿を通り越して害悪
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況