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/25(日) 15:09:57.30

批判するならそれだけの根拠と対策具体的に分かりやすく言えって言ってるだけなのに、「僕ちんの発言封殺されてる！ふんぎゃあー！」とか、ほんとにガキみたいな奴だな

2023/06/25(日) 15:32:13.94

プロトタイプひとつ完成させられないやつが、git のコードの品質語ってる時点で爆笑ものｗｗｗｗｗｗｗ
ねえ、ねえ、はずかしくないの？
それとも完成したからもどってきたの？
何で君のつくったツール誰もつかってないの？

2023/06/25(日) 21:03:54.64

>>654
都合のいい情報しか見えないお前ら信者には情報共有能力なんて無い
この状況がその証拠

2023/06/25(日) 22:18:15.12

・俺はgitのバグのせいで使うのやめた
・でもお前らは都合のいい情報しか聞く気がないから詳細は教えてやらん

こういうことか

2023/06/25(日) 22:41:33.10

>>658
バケツだかゴミ箱の話は都合が悪いので見えなかったことにするという意味じゃないかな？

2023/06/25(日) 23:01:47.85

>>658
ちゃうで。
既に公式に公開/共有はされてて、知らないなら、君が目に入れてないだけ。
俺に絶賛粘着中の連中も実は全部詳細を知ってるし、
俺の代わりに>>654に回答することも出来るはずだが、(一応待ってみた)
実は貢献度が俺以下のゴミだとバレるのが都合が悪いのか、無いことにしてるだけ。

多分君はこのしょうもないやりとりに参戦しない方がいい。君にとっては意味がない。
まあこのスレのGit信者の民度なんてこんなもんですよ、都合が悪い情報は隠蔽ってね。

2023/06/25(日) 23:07:30.47

Gitのコード品質が気に入らないならフォークして互換性を保ったまま改修したら多くの人に喜ばれるんじゃないかな
単なるコード整理のプルリクは取り込まれにくいだろうし

2023/06/25(日) 23:13:41.79

>>660読んでも>>658のどこが違うのかさっぱりわからんが。

バグチケットなんかしょっちゅう出てると思うがgitを使うことを断念するくらいのバグってなんなのか
単純に興味があるし、それを頑なに隠す理由というのもよくわからん。
git信者じゃないんだったらバーンと書いちゃえよ。

2023/06/25(日) 23:19:31.50

すでに公式に共有されてるならURL貼ればいいのにね
俺らにとって都合が悪いと思ってるなら尚更
虚言癖もここまでくるとほんとヤバいな

2023/06/25(日) 23:55:41.44

>>662
Git信者の隠蔽体質を証明する為にも、俺は貼らないことにする。
URLを知ってる奴が多数ここにいるのは明白なので、情報共有する気があればそいつらが貼ればいいだけ。
そうならないのなら、このスレはその程度って証明になるだけ。

> gitを使うことを断念するくらいのバグってなんなのか
使いたい機能がバグってたから使えないってだけの話だよ。

2023/06/26(月) 00:22:40.56

長文くん長文やめちゃったの？
流石に自分のウソ突き通すの辛くなったか…この嘘つきめ

2023/06/26(月) 01:20:45.72

最後にレスした方が勝ちゲーム
いつ終わんだ？

2023/06/26(月) 07:30:29.11

>>594
大分遅くなったけど、ありがとう

2023/06/26(月) 07:33:52.34

>>666
レスバは始めた時点で敗北者だからなあ……

2023/06/26(月) 20:47:11.43

>>612
言語に上級者もなにもないだろ
どんな言語でもISOの規定を見れば全部書いてあるし

2023/06/26(月) 23:27:49.31

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

で，これどうなったの?
長文くんがこれに一切反応しなかったら逃げたって認定するね

2023/06/27(火) 05:44:42.45

>>652
> 普通の人
ちな、その「普通」はこのスレの『三流』の連中には当てはまらない
「○○すごい＝○○使ってる僕すごい」になるのは、自分では何も作ろうとしてない証拠だから
『本来なら普通は』自分の事に忙しく、ツールや他人の状況なんて(バグに命中しない限り)どうでもいいものだ

2023/06/27(火) 11:02:55.19

進捗履歴なんかGitHubでProject作ったあとにRoadmap表示して、進捗はmilestoneを追加し、関連付けた
issueにはやったこと書いて、milestoneの進捗を更新すればいいだけじゃね？webで完結できる。
　PWA対応になってるからアプリにしたいならChrome、Edge、safariのどれか使って勝手にすればいい。

2023/06/27(火) 12:22:09.28

>>671
長文君や
それ思いっきりブーメランで自分に刺さってないか「自分では何も作らない」
それとも作るって言ってたやつできたの？

2023/06/27(火) 12:52:46.00

長文くんはなんで隔離スレから出てきたの？

2023/06/27(火) 23:09:39.32

>>673
仮にそうだとしても、このスレの連中が何も作ろうともしていない事実は変わらない
他人のアラ探しに勤しんで自分のことは常に棚に上げてきたヒトモドキばかりなのも知ってるけど
管理する物もないのに、Git触って満足しててどうするよ？

2023/06/28(水) 00:06:07.05

あぼーんばかりだねこのスレ

2023/06/28(水) 00:21:55.51

>>675
gitスレでgit関連の話をしている人たちに
git使って管理しているソフト等の話をgitスレでしないのなら
何も作ろうとしていないということだ、とケチをつける長文君

2023/06/28(水) 03:07:01.90

>>675
linux kernel のコード書いてるけど？

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

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

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