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/06/28(水) 07:04:44.26

>>677
前から思ってるが、どうにもお前ら文盲だよな。

お前らは勘違いが酷すぎるんだよ。
本来、自分が書いてないコードが稚拙であろうが知ったことではなく、発狂すること自体がおかしい。
そうなってしまうのは、お前らには「自分のコード」が存在せず、「Gitのコード＝ぼくのコード」になってるからだ。

> 素人の欲しがるようなソースコード管理ツール (567)
以前からそうだったが、これも勘違い甚だしい。
素人であれ、それはその人が何時間もコードと格闘した成果物であり、保存したければ保存すればいい。
コードと格闘する気もない奴が揶揄してるようでは話にならんよ。
しかもGitのコードが素人以下なのを認識出来ない程度の腕前(＝素人以下)の癖にね。

これらはお前らがコードを書くのを止めてる事に起因してる。
多少でもコードを書き続けてれば、こんな勘違いはしてないだろうよ。

それで本末転倒を多少でも改める気になって、しかし何を書くべきか分からないのなら、
「Gitのコード＝ぼくのコード」の妄想を現実にしてしまえというわけ。
これがお前ら的に最大級「ぼくすごいじる」を流せる方法だろう。
Gitのコードは現時点で素人以下のゴミだから、同様に素人以下のお前らが糞コードを挿入しても大した問題にはならない。
まるでレビューが機能してないから、お前らの糞コードでも問題なく通るはず。
(心配せずともお前らが遠慮したところでインド人が糞コード挿入しまくるだろうし)

俺はお前らが何をやってるかなんて興味ないし、ここでする話でもない。
ただ、コードを書いてるニオイがしないのに勘違いしまくってるお前らに、ちょっと突っ込んでるだけ。
そして初心者には、手段の目的化の罠に嵌るなよ、と言いたい。

2023/06/28(水) 08:35:33.63

>>679
gitスレでgit関連の話をしている人たちに
コードを書いてるニオイがしないからコードを書いてないに違いない
と言いがかりをつける鼻詰まりの長文君

gitは仕様もコードも糞だ、俺ならもっと良い管理ソフトをつくれると
宣ってスレを立てたけど、まったくコードを書かないまま被害妄想を
起こして逃げ出した長文君に、あのソフトどうなったと尋ねると
発狂したことにされてしまうらしい

2023/06/28(水) 09:17:40.93

>>679
それよりも、今あるGitのホスティングサービスだけで君の妄想した機能はすでに実装してあるって
過去何度も手順やサービスの具体名で書いてあったのに、なぜそれを毎回無視するの？

2023/06/28(水) 10:48:39.33

>>679
親前朗読定期

2023/06/28(水) 11:28:33.08

長文くんはアプリケーション作ったことないのになんでそんなに偉そうなの？

2023/06/28(水) 12:04:01.80

妄想の中の愚かな「お前ら」に向けて書いてるからさ。
実在する個々の読み手に向けて書いてるわけじゃないから各位スルーするように。
戻ってきた動機がさっぱりわからないんだけど、ちらほら見られる彼への反応が餌になっている可能性がある。

2023/06/28(水) 13:38:22.05

初心者の質問があると湧いて出るので、ウォッチしていて自分の味方になってくれそうな人探してるんじゃないかな
迷惑なはなし

2023/06/28(水) 23:12:12.37

>>681
ホスティングサービスが欲しい訳じゃないから

2023/06/29(木) 00:58:18.38

>>686
機能が欲しいんだろ。
ホスティングサービスかどうかとかどうでもいいだろ。

2023/06/29(木) 07:46:32.40

いまいちブランチの使い方がわからないんだけど
masterへコミット出来る人は限定して運用すべきなの？

2023/06/29(木) 10:59:31.85

>>688
可能ならそうしたほうが無難だと思うけど
絶対というワケでもない
セクションや機能追加などでブランチきって
出来たら統合して
不要になったら削除というふうに使ってる

2023/06/30(金) 14:01:02.61

>>688
masterへのコミット制限はかけといた方がいい。特に社外の人とかコントリビューターに与えたらダメ。
　PRでメンテナーの承認(レビュー)を受けたものが個人のブランチから現在活性中のdevelopブランチに
マージされ、製品が完成したらメンテナー自身がmasterにマージするようにしておけばmasterに変な
コードが流入するリスクも避けられる。
　ただし製品出荷前/接合テスト前でバージョン管理前だよってなら、その限りではないが。

あと一般利用者にはリポジトリの設定変更させないようにもしといた方がいい。

2023/06/30(金) 17:37:04.62

いちいちコードレビューなんてやってられないわ
よほどひまな職場なんだろうな

2023/06/30(金) 18:07:43.82

コードレビューをしないから
忙しくなってるんだよ

2023/06/30(金) 19:42:24.21

>>688
ブランチは並行して複数並べられるというメリットを活かして、release,main,developといった位置付け別と、さらに細かく実装機能別にブランチを作るのがいい。実装機能別は１機能１ブランチでもいいくらい。

2023/07/01(土) 00:13:57.08

コードレビューやってられないのは50%ぐらいレビューされる側の問題
分かりにくければ「お前のコミット分かりにくすぎるのでもっと分割してくれますか？」と伝えるべき

**デフォルトの名無しさん** (JP 0He7-ePcp) · 2023/07/01(土) 01:27:44.90

>>692
なんで？
いちいち他人に見てもらわなきゃかけないのか

2023/07/01(土) 02:37:41.90

>>695
お前、一人でプログラミングしてるの？
人間って一人でできることには限界があるんだぜ。

2023/07/01(土) 07:57:57.36

>>690
仕事したこと無さそうな頭でっかちww
実際には担当がガシガシ変更して、そのままリリースされてることなんてザラ。

プログラマなら誰でも名前くらいは聞いたことがあるソフトに従事してるけど、うちの所だけでも20人いるけど一人も全体を把握してる人はいないよ

2023/07/01(土) 08:18:09.45

俺もプログラマな誰でも名前くらいは聞いたことが有るソフトを作ってるよ。なんの自慢にもならないけど。

2023/07/01(土) 08:32:39.81

おまえら個人名はいらんので、会社名出してくれない？
その会社とつきあうか参考になりそうなんで

2023/07/01(土) 11:22:09.50

>>698
匿名掲示板ならいくらでも話を盛れるという好例

2023/07/01(土) 11:49:41.48

信じたくないなら信じなくてもいいけど、俺はすごいんだ

2023/07/01(土) 13:15:50.29

長文くんのつぎは自称自分スゴイマンかよ

2023/07/01(土) 15:18:55.67

可哀想にね
妄想と現実のギャップで苦しんでるんだよ

2023/07/02(日) 22:54:33.75

>>697
そんなことしたら、最悪ビルドも通らないソースを運用が始まった製品のmasterに直接コミットされる
可能性もあるでしょ？
　俺ならブランチでビルドエラーが出るどころかjestやlintも通らないようなものは、エラーがなくなる
までdevにすらマージさせないて修正させるよ。

2023/07/02(日) 23:10:04.39

チームの状況に合わせて臨機応変に運用を決めればいい

2023/07/02(日) 23:29:14.65

>>705
それはヤバいで。
仲良しで優秀な集団ならいいけど、以下のようなのがいてブチ壊していくから。

〈組織や生産性に対する一般的な妨害〉
○組織と会議
・何事をするにも「決められた手順」を踏んでしなければならないと主張せよ
・「演説」せよ。できるだけ、頻繁に延々と話せ
・議事録や決議の細かい言い回しをめぐって議論せよ。あらゆる決断に懸念を示せ
○管理職
・指示を誤解せよ。長ったらしい返信を送れ
・士気を下げるために、不相応な作業員を昇進させよ
・できる作業員は冷遇し、仕事に不条理な文句をつけよ
・重要な仕事は必ず会議を開け
・もっともらしい方法で、ペーパーワークを増やせ
・手続きに必要な承認者は、ひとりで十分でも3人の認可を徹底せよ
○従業員
・のろのろと働け
・できる限り自分の仕事を中断せよ
・何回も繰り返し尋ね、不要な質問で主任を困らせよ
・質問をうけたら、長ったらしい、理解し難い説明をせよ
・とぼけよ
・面倒なことに巻き込まれないように、できる限り不機嫌にふるまえ

2023/07/02(日) 23:38:58.18

職場の実体としてそうであるってのはまあ仕方がない面もあると思うけど
それを正道であると思って語っちゃうのはちょっとやばい
水は低きに流れていくんだからせめて恥ずかしがらんと

2023/07/03(月) 01:40:46.25

チームの人間が信用できないんだね
常にギスギスしてそうで可哀想

2023/07/03(月) 06:29:04.98

>>706
何かと思えばこれか。
toyokeizai.net/articles/-/682357
内容も歪んでるなあと思いきや、著者が河合薫で納得だ。
権限が与えられてるのに執行しなかったのなら、それもただの責任逃れでしかない。

まあそれはさておき、お前らニート過ぎ、精神論過ぎ。
新入社員からベテランまで職場には居るのだから、技術レベルが揃ってることなんてあり得ない。
お前らが空想してる職場なんて存在しない。(少なくとも日本には。海外はどうなんだろう？)
rejectすれば自動的に改善されるわけでもない。

そもそも職場の場合、相手の技量を理解した上で仕事を振ってる。
量が問題なら、最初から量を減らしてるし、
質が問題なら、事細かく、場合によっては付きっきりで指導してる。
rejectするのが仕事じゃないんだから、
将来的にrejectしなくても済むようにあらかじめ手を打つんだよ。
新入社員が無能だからって、何もやらせないと上達もしないだろ。
新入社員なんて無能だという大前提で、それでも可能なように手回しして振っていくんだよ。

OSSの場合はこれが出来ないからreject頼りになるのはある程度致し方ないが、それが理想でもない。
それは育成過程無視のただ乗りでしかないし、実際お前らの理想を実行してるGitは完全に糞コードだし。
あれマジでCの職場だとグーで殴られるレベルだぞ。
rejectだけに頼ってると、rejectされるかされないかだけが基準になってしまうのも問題なんだと思うぜ。
職場だと、「今回はもうこれでいいが、次からはここはこうしてくれ」とか言うからね。
(というより、そういう妥協が出来る部分を技術レベルが低い奴に振る)

2023/07/03(月) 07:10:29.97

> あれマジでCの職場だとグーで殴られるレベルだぞ。

じゃあなんでお前のほうが殴られたの？

2023/07/03(月) 08:31:58.63

伽藍とバザールの話蒸し返してるし
伽藍は伽藍でハードル高くして衰退していけば良いのよ

2023/07/03(月) 10:34:59.49

長文くんお帰り

2023/07/03(月) 12:55:21.86

長文くんはろくにソフト作ったことないのになんでそんなに偉そうなの

2023/07/03(月) 12:58:19.02

頭デッカチなっかだよな
ネット上のサンプルプログラムをいじってるだけの人と
数十万行にも及ぶシステムを開発してる人では全く違うしな

2023/07/03(月) 13:08:24.54

反応はあっちのスレでやってくれよ。

2023/07/03(月) 13:49:06.05

masterへのpushが制限されてる職場で、pullリクエストにrejectなんて反応を返すとこは経験ないな
普通reviewして修正を必要なら繰り返してから取り込む

2023/07/03(月) 21:42:56.65

個人でgit管理って意味あんのか？
ついついブランチで触るべきでないところ(依存関係ないところ)いじっちゃうんだけど

2023/07/03(月) 22:14:54.54

>>711
それなら「糞コードでも受け入れるのがバザール戦略だ」と開き直るべきで、発狂してるのは矛盾してるだろ。
ただ>>39なら、「(表面的であれ)動く限りコードの質は問わない」でもないんだろ。

>>716
それを言ってるんだけどね。
複数回reviewで落とすのが見えてたら、最初から「こうしてくれ」と明確に指示しておくべきだし、
そうしてないなら「先に言えよ糞が」とキレられて当然だろ。
お前らのエアプ感が酷いが、仮にエアプであったとしても、この辺は分かると思うのだけど。
後輩や部下を虐めるのが仕事ではないし。

reviewで落とせば改善する、という感覚がおかしい。落としただけでは何も改善しない。
改善させる為には、どこをどう変更しろ、その理由は云々、と説明する必要があって、
なら最初から説明しとけば一発目のreviewで通るし一番早い。
これが理解出来てないお前らの話は、まるで現実感がないんだよ。

だから複数のreviewが、或いはreviewが必要なこと自体がマネジメント不足とも言えて、
相手の技量を知ってる上で(用意周到に)振ってるのだからそいつが全力出してればおｋ、
reviewなんて仕事を振る段階で全部終了してる、というのが究極のマネジメントだ、とも言えるわけ。
> 実際には担当がガシガシ変更して、そのままリリースされてることなんてザラ。 (>>697)
ってのが果たしてそうか？はあるにしても、全くナンセンスというわけでもない。
少なくとも、難易度が高い仕事を技量の高い奴に振る程度の事はどこでもやってるし、
これが正しく嵌ればこうなるし。

そして実際reviewを機能させるのは難しい。
現実的にはGitのように回覧しただけで出来てるつもりになってる馬鹿が大半だと思うよ。
全員の技量が揃っていれば機能するが、そんな職場は基本的にないし。
ただOSSの場合は上記の究極のマネジメントは出来ないので、reviewでrejectを使うしかないのも事実。

2023/07/03(月) 22:25:14.80

>>718
伽藍とバザールの違いだけの話
関わらなければ良いだけだよ

2023/07/03(月) 22:30:46.27

>eviewで落とす

なんのことを言ってるんだろう

2023/07/03(月) 22:39:27.52

>>717
お前の記憶力次第だな。10年前、20年前の自分とコラボできるか想像しろ。1年も使わないような使い捨てプログラムなら多分必要ない

2023/07/04(火) 05:26:31.65

>>717
1人だろうと複数パターン試してから本実装決めたりすることあるだろ
ブランチ使えばパターン切り替えが簡単にできる

2023/07/04(火) 13:28:29.54

>>717
複数のプラットフォームを扱ってて環境変えたら(例えばフレームワークのバージョン上げた)、どんな影響
あるか確認するためブランチ切ってテストすることは割とやる。
　例えばelectronのバージョンあげてみたらWindowsは無傷だったがMacはxcode SDKのバージョンアップ
まで必要だったりして、iOSアプリの制作に影響出そうだから今回は面倒だからやめるか、とか。

2023/08/02(水) 13:16:36.57

WindowsのSourceTreeなんですがたまに境界線が動かなくなります
これの治し方と起こらないようにする方法ってありますか？

**hage** (ﾜｯﾁｮｲ be03-6+wX) · 2023/08/03(木) 11:27:17.93

https://twitter.com/col_richie/status/1239501620645228544

SCCS, RCS, CVS, SVN, git...
プログラマー達は一体どれだけバージョン管理ソフトウェアに翻弄されれば気が済むのか。

ソースコードのヘッダーに必要事項をコメントし、その時点の一式を
その日の日付の名前のついたディレクトリーに保管しておけば十分。
過去の検索はdiff,grep他、既存コマンドでできる
https://twitter.com/5chan_nel (5ch newer account)

2023/08/03(木) 11:51:16.55

>>725
スレチ
こちらへどうぞ
gitを使わずにディレクトリコピーでバージョン管理2
https://mevius.5ch.net/test/read.cgi/tech/1665692817/

2023/08/06(日) 15:35:17.61

sageも使えない時点でスレ荒らしなんだから構うな

2023/08/06(日) 16:46:06.19

Git v2.42.0-rc0

2023/08/11(金) 07:18:46.01

Git v2.42.0-rc1

2023/08/15(火) 21:30:08.31

ゲーム業界とか未だにSVN使ってるとこ多いけどGit LFSでは駄目なん？

2023/08/15(火) 21:48:57.84

そういう現場知ってるなら直接聞いてみたら？理由は俺も興味ある。

2023/08/16(水) 02:43:30.27

large file は大抵バイナリで差分取ったりマージしたりできないので何で管理してもあまり変わんないよね。
それこそオブジェクト・ストレージとかに置いてリンクだけ git で管理するとかが便利だったり。

2023/08/16(水) 02:51:59.56

「大容量ならLFS使えばいいじゃん。何で古臭いsvnなんか使ってる？」とでも言いたげだな…

2023/08/16(水) 08:26:28.84

変える理由がないからだろ
今明確に困っている事があり、それがgitで解決出来る場合のみ、変更するに足りる
そうでなければ今まで通りが一番トラブルがない

だいたいgit(2005)も十分古臭いし

2023/08/16(水) 08:33:10.63

git のブランチ・モデル使えないだけで、かなりの損失だと思うけどな、ま、他人事

2023/08/16(水) 08:43:20.45

Git v2.42.0-rc2

2023/08/16(水) 09:18:06.02

>>735
使う必要がないと分からないのはお前の問題

2023/08/16(水) 09:28:54.97

>>734
なんとかバケツの方はどうなったのよ?
とりあえず作ってあるとこまで仕様のテキストでもコードでもあるものリポジトリで公開してみてよ
みんなで見よう

2023/08/16(水) 09:34:15.84

ああそういえばsvnもブランチは切れるぞ
ただ集中型だから各ディレクトリになり、gitとは形式が異なるが、それ用に環境作ってあれば何ら問題ない
だからブランチが使えるだけでgitに移行する理由にはならないし、そう思えるのなら見識が狭すぎる

2023/08/16(水) 11:44:03.25

色々理由はあると思うけど、
- アセットなどのバイナリファイル主体だからいちいちブランチを切り替える意味があまりない
- ファイルのロックが簡単
- 非プログラマでもgitよりは扱いやすい
だいたいこの辺りじゃね？

バケツ野郎じゃないけど、何でもかんでもgitでやればいいと言うのはどうかと思うぞ

2023/08/16(水) 20:42:47.86

アーティストはコマンド直接は使わんし管理ツール作り直すのもめんどいし

2023/08/17(木) 02:13:40.06

>>739
ブランチ切れるかどうかなんて問題にしてないよ
ブランチをどのように活用できるかの問題
お前まともに git 使ったことないだろ

2023/08/17(木) 08:31:55.84

>>742
gitを使えば全てが解決して幸せになれると信じるgit統一教信者乙

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

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

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

多分な、(オープンソース等)ある程度rejectする前提ならgitのように気軽にブランチ丸ごと捨てられる構造が便利だが、
(プロプライエタリ等)最終的に全員のコードをマージする前提で仕事配分してたら、svnでも、ブランチ無くても、大して問題ないって事だと思う

2023/08/17(木) 08:43:35.27

>>743
git 使ったことないのが丸わかりの意見でw

2023/08/17(木) 09:43:17.45

>最初からマージした状態で作業を進めていった方が理論的な効率は高い」ということ

同じファイルを触ってたらわけわかんなくなるな。
その場合VSSみたいにファイル単位でロックする仕組みが必要かな。

2023/08/17(木) 10:28:22.80

>>743
このスレ立てた人だよね?

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

否定しないなら同じ人って判断するけど、とりえあず顛末だけでも書かないとここで何言っても
他の人からは「投げっぱなしのテキトーな人」って目で見られて誰も聞く耳持ってくれないと思うよ?

2023/08/17(木) 10:29:50.40

みんな分かってるから触れなくていいっての
マジで

2023/08/17(木) 12:11:03.75

>>745
> 同じファイルを触ってたらわけわかんなくなるな。
その通りだが、それがどれだけあるかという話なのと、アナログに回避出来るという事。

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

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

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

ちなみにsvnのブランチなら、他人の作業状態もそれなりに見える。だから遅れてる部分も丸見えではある。
gitの場合は完成品を納品するシステムだから、遅れてる奴が黙ってたら全く検知出来ない。
勿論この辺はgitではなく上位戦略で回避すべき案件ではあるが、実際に問題になることもあるとは思う。

2023/08/17(木) 12:18:48.57

gitを分かってないから、svnの優位点語るのに頓珍漢なことしか言えないんだろうな
svnも分かってるかどうか(実際の現場でどのように使われるかに関して)も怪しい

2023/08/17(木) 12:52:59.75

ようはトピックブランチを使わずにmasterに直接commit/pushするようなやり方だろ。
ひとり開発でならよくやるな。

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に対応してないところくらい。