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/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とする場合が混在してて分かりにくいわ
設計がでたらめなんだろうな

2023/09/30(土) 21:49:53.62

>>892
別のものを指してるんだよ。
origin/branch は remotes/origin/branch の略でただのブランチ名。ローカルにあるリモート・ブランチのコピーを指す。ほとんどのコマンドで使える。ネットワーク切れててもアクセス可能。最新版じゃないかもしれない。
origin branch は特定のコマンドだけで受け付ける形式で、リポジトリ名とブランチ名の2つを指定して、ネットワークの先にあるリモート・ブランチそのものを指す。
その特定のコマンドでローカルにコピーを作って、コピーを操作するというのが git の思想。マニュアルか良い参考書を読め。

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

それが設計の甘さだろ
素人設計っぽいし

2023/09/30(土) 22:14:28.90

>>894
これより良い設計があると思うならお前が作ってみせろ。俺が今から作っても同じ設計になるわ

2023/09/30(土) 22:31:26.06

おかえり？

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

>>895
別にいいけど、見積してほしいなら営業経由でお願いします

2023/09/30(土) 23:21:44.57

>>897
営業の連絡先教えて

2023/10/01(日) 00:26:47.74

Linusを素人呼ばわりする人の実績を知りたい

2023/10/01(日) 11:56:13.91

>>892
基本的にリモートリポジトリから何かしたいコマンドはorigin branch
それ以外、つまりローカルブランチも対象になるコマンドの場合はorigin/branch

pull/fetch/pushはローカルリポジトリに対して行うコマンドでないことは明白だろう、だから前者を使う

2023/10/02(月) 09:35:59.77

20年振りに自分でプログラミングするんだけどGitの概念がわからなすぎて辛い・・・
リポジトリだのブランチだのステージングだのコミットだの今までの言語概念になかった用語多すぎて覚えきれない
今のプログラマ仕事のPG以外にどんだけ難しいことやらされてるの・・・

2023/10/02(月) 10:33:16.49

そういう場合はGUIのGitツール使えばいいと思うよ。
ただしコンフリクトの修正観念だけは知ってないと、にっちもさっちも行かなくなるしSourceTreeや
Github Desktopみたいにリポジトリを回復するためにgit stash相当を実行しますみたいなコマンドに
「はい」を選択すると、自分の修正したソースがきれいさっぱりなくなって絶望することになるけど。
　実は自分の修正差分は退避されてるだけなので復帰は十分可能なんだけど新人さんはパニくる。

2023/10/02(月) 10:33:19.63

そういう場合はGUIのGitツール使えばいいと思うよ。
ただしコンフリクトの修正観念だけは知ってないと、にっちもさっちも行かなくなるしSourceTreeや
Github Desktopみたいにリポジトリを回復するためにgit stash相当を実行しますみたいなコマンドに
「はい」を選択すると、自分の修正したソースがきれいさっぱりなくなって絶望することになるけど。
　実は自分の修正差分は退避されてるだけなので復帰は十分可能なんだけど新人さんはパニくる。

2023/10/02(月) 10:36:05.48

すまん。大事でもないのに2回も送信を。

2023/10/02(月) 10:49:59.75

>>901
待てや、20年前でもコミットとかブランチとか普通にあっただろ？どの時代から来た？
ステージングは git 特有だが

2023/10/02(月) 10:50:29.34

入門書一冊読めば解決するし、その価値があるよ

2023/10/02(月) 10:52:28.41

GitってよりSCM全般の話に読めるけどねその中だとステージングくらいじゃないGit固有って
用語にしたってもどれも20年前の時点で一般的だった言葉だと思うけど

2023/10/02(月) 11:02:09.86

UNIXだったりcobolやらjavaやら仕事でやってたけどリポジトリなんて聞いたこともない単語だ
王様のブランチと結果にコミットかて
そもそもソース管理なんてISO14001遵守の職場でもコピペ日付だったしそれでなんの不都合もなかったぞ

あんだけやってたのにもはやvi操作すらおぼつかん50近くにもなってバックレたい気分

2023/10/02(月) 12:01:08.22

gitの開発MLに以下の題のパッチが流れているな。

Initial support for multiple hash functions

2023/10/02(月) 13:07:10.69

>>908
当時から技術についていけてなかったんだな。そういう駄目な鍛えられ方したやつは今でも git 無しでも大丈夫やろ。
git 理解したら、若い時の苦労はなんだったのか？最近の若い奴らは恵まれ過ぎ！とか愚痴れるぞ

2023/10/02(月) 13:22:55.35

昔ながらのやり方じゃなきゃヤダとか言ってるわけじゃないんだからそうマウント取ってやるもんじゃないよ
そういう現場だってあってもおかしくない
これから学んでいけばいいだけだ

2023/10/02(月) 15:14:29.97

gitは言ってみればCVSやSVNのアンチテーゼとして生まれたんだから、今時アナログ方式のコピペ日付しか知らん人にいきなり触らせようっても敷居が高すぎる気がする

2023/10/02(月) 15:39:03.67

いまでも git 使ってない現場はいくらでもあるけど 15年以上前からあるし、
svn が 20年前、cvs は30年前、rcs なら40年前からあるので使って無くたってコンピュータ関係の技術勉強してれば用語くらいは知ってるだろ。

2023/10/02(月) 17:38:30.99

RustはGit必須みたいなもんだから
Rustに人が寄り付かんのはそれも原因の一つかもな

2023/10/02(月) 17:47:06.79

SCMが当たり前になったのはGitとGitHubが大きいかと
最初は戸惑うかもしれんが慣れれば便利だよ。新しい言語覚えるよりは楽だと思う

2023/10/02(月) 18:26:48.75

git 最初触った時はGUIだったが、なんかピンと来なかった。
CLIで手順通りを繰り返したらCLIの方が好きになった。

2023/10/02(月) 19:35:19.50

>>908
使わなければいいだけでは。
IDEや補助輪と同様、初心者にこそ恩恵があり、無くても問題ない奴には何も恩恵がない。
910みたいな他でマウント取れない馬鹿には都合がいい程度の難度だから、馬鹿には大受けのようだが。
あと10年もすれば同様に、「(gitを使わずに済む)最近の若い奴らは恵まれ過ぎ！」とか言われてるだろうよ。
それくらい、ツールとしては糞だ。

2023/10/02(月) 19:39:08.72

>>913
勉強してこなかったんだろ
察してやれよ

2023/10/02(月) 19:41:35.41

お、長文くん来たか？

2023/10/02(月) 23:05:00.22

もはやただの罵倒でしかないし悪化してんな
かわいそうに

2023/10/02(月) 23:35:51.73

GUIの方で使ってるけど名前被りとか他の人のブランチに混ぜ込まれた結果妙なことになったりと複雑怪奇な流れになってるわ
どっかでデグレ起こしてそうだけどちゃんとマージ出来てるのかなぁ

2023/10/03(火) 01:09:10.30

FreeBSD2.2.8ぐらいからUNIXを触るようになったけど、当時最新のソースでbuild worldをするためにCVSの知識は必要で、当時の教本にも書いてあったような記憶。
git pull相当をするだけだったけど。

2023/10/03(火) 06:06:54.45

新人がパニクるのを通過儀礼とするのは昭和ですらありえない価値観だ
実際、そんな糞ツール他にないだろ
これを異常だと感じれないのだから、信者は相当歪んでしまってる
誰が設計しようが、糞は糞だよ

2023/10/03(火) 08:05:28.16

>新人がパニクるのを通過儀礼とする

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

2023/10/03(火) 11:25:53.28

386BSD使っててFreeBSD98もbuildしたけどCVS要らなかった希ガス

2023/10/03(火) 14:36:02.52

長文くんは自分が理解できないだけのを、初心者には理解できないに、擦り替えるから。
今 git を使ってるのべ1億人の人たちも最初は初心者だった。（1億は github のユーザー数な）

2023/10/04(水) 19:57:12.00

むしろ新人に概念教えずにExcelやメモ帳で開いてコマンドコピペで設定しろって新人教育してるから

例えばmavenリポジトリ設定してても、新人はリポジトリって知らないってなっちゃう。

　管理者(メンテナー)だけにファイル管理任せたり、ファイルサーバーにtarball置いて、これ使ってね

ってするのは一見楽そうなんだけど、た担当者不在やちょっとし不注意で全員地獄に落ちるような運用は

よくないよ。

2023/10/04(水) 19:58:51.90

あっとコピペミス。

た担当者不在やちょっとし不注意
→担当者不在やちょっとした不注意

2023/10/06(金) 10:17:42.42

前にgitに一時期アクセスできなくて騒ぎになったじゃん？
あれって自分の会社でgitサーバ建ててなくてgithubにリポジトリ置いてたとこだけがそうなったってこと？

2023/10/06(金) 10:43:15.32

50近くでこれじゃあb55f-VEJPは色々大変そうだなあ