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/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は色々大変そうだなあ

2023/10/06(金) 12:48:24.76

>>929
それOSDNと混同してない？
gitはあくまでコラボレーションサービスを実現するためのコマンドツール。
GitHub、GitLab、OSDNなどはgitサービスを提供してるwebホスティングサービスで全然違うからね。

2023/10/06(金) 13:23:15.43

githubもgistも時々落ちるからな
だがgithub使ってる人はローカルにもrepository持ってるはずだから
複数人居たら居たでローカルのrepositoryで生き残ってる人のでどんどん進めていけばいいだけ

2023/10/06(金) 18:07:39.93

>>931-932
ありがとう。大分使い方も用語も覚えたけどやっぱ年取ってから全くの新しいこと覚えるのは疲れる

2023/10/16(月) 16:22:53.30

https://i.imgur.com/aPRgNUK.jpg
良ければ一度お試しください
ik..tk N-G用

2023/10/16(月) 17:15:34.57

>>934
めっちゃ簡単よ

2023/11/03(金) 22:56:38.45

Git v2.42.1

2023/11/03(金) 22:57:57.68

Git v2.43.0-rc0

2023/11/09(木) 13:04:20.29

Git v2.43.0-rc1

2023/11/12(日) 00:53:40.69

混乱を引き起こしがちなGitの用語まとめ
https://gigazine.net/news/20231111-confusing-git-terminology/

**あぼーん** · NG

あぼーん

2023/11/13(月) 11:26:23.20

>>940
これはやるべきだな

2023/11/15(水) 08:50:03.05

Git v2.43.0-rc2

2023/11/16(木) 21:17:38.48

gitlabで教えて下さい。
前回のアーティフクトから今回のビルドの
前提条件として呼び出すコマンドってあります？

ようはlinuxで今回の対象となる関連性のある生成物が
存在した上でピンポイントでビルドしたいんだが…
それが無いと今回のビルドが通らないから…
全量ビルドは時間かかるから回避したい。

2023/11/21(火) 03:57:24.26

Git v2.43.0

2023/11/21(火) 09:16:25.04

それはホスティングサービスの範疇外なのでドキュメント読むかソース読むしかないな。

2023/12/12(火) 21:38:16.44

大変申し訳ありません。
Gitをインストールしたいのに公式から「64-bit Git for Windows Setup」でクリックしたら
「a93c7233-5099-4ce1-8597-efb65113b310」がダウンロードされたものの
クリックすると開くアプリを選択してくださいと表示されます。どなたか原因わかるかたいませんか？

2023/12/12(火) 21:45:55.02

原因は知らんけどファイル名に.exeつけて実行すれば多分いけんじゃねーか

2023/12/12(火) 21:48:24.92

>>947
盲点でした。
昔はそうやってきたのにいつの間にやらインストーラーが自動的にできてるので
忘れてました。申し訳ない。ありがとうございます。

2023/12/12(火) 21:53:17.87

へー良かったじゃん俺は昔も今もそんなやべーコトやったことねーけど

2023/12/13(水) 12:17:52.84

>>948
公式に指摘して修正を待ったほうがいい。
万が一ウイルスだったら面倒。

2023/12/13(水) 12:57:12.86

ブラウザがファイルの受信完了を検知できなくて、ダウンロード完了後にファイル名をリネームする前で止まっている動きじゃないの

2023/12/13(水) 13:42:26.90

ハッシュ値くらい見てんだろうよさすがに

2023/12/17(日) 12:12:25.07

大した不満も出てないしあと20年はgitの天下かな

2023/12/18(月) 14:50:59.99

現在の最大のソースであるLinuxのカーネルとWindowsのソースをgitで管理してるから、
当分gitの覇権は揺るがないでしょ

2024/01/01(月) 07:07:12.99

SQLiteがバージョン管理システムとしてGitを採用しない理由
https://gigazine.net/news/20231231-why-sqlite-does-not-use-git/

2024/01/01(月) 17:16:07.39

git は常にPCの前に座っているプログラマ向けで、抽出も整形も必要ならいくらでも自分で専用のスクリプト組むし、git を部品に使って試行錯誤で自分環境DIYするようなトップ層向けツールなので仕方ない。
スマフォで綺麗に整形された変更履歴みたいとか、インストール一発で使える環境欲しいとか言い出すようなカジュアル層には向いていない。
おばちゃんの買い物にはF1カーもラリーカーも必要ないのと一緒。

2024/01/01(月) 23:00:32.79

Fossilってベースとなるコマンド体系はGitからそのまま引き継いでいて、All-in-one-gitとかBetter Gitともいうべきものなんじゃないの
Fossilを使うからGitは使ってませんっていう発言は奇妙に感じる
俺は明太子しか食べないのでタラコなんて食べません的な違和感