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

2022/11/18(金) 09:43:06.36

①gitは情報共有ツール、他人や未来の自分に「効率良く」情報を提供し情報を利用するのに使う
②gitはパッチ管理ツール、上記①を実現するためにコミットを作成、検索、編集、再利用するのに使う
③gitは整理整頓ツール、上記①②の目的で日頃から不要な情報を削除し有益な情報のみを残すようにするのに使う
rebase は②のコミットの編集・再利用するためのコマンドで、主に③の目的で使用する

2022/11/18(金) 12:31:12.44

長文くんは毎回意味のわからない喩え(今回も卒アルがどうとか)使ってるけど、あれでわかりやすく説明できてると思ってんのかね

2022/11/18(金) 16:55:16.94

俺が例にするとしたら「実験ノート」と「科学論文」かな。
長文君とかが欲しがってるのは「実験ノート」を録るツール。
git とかが提供しているのは「科学論文」を共有する論文誌。

「実験ノート」はありのまま全ての情報を記録するのが目的で後から修正したりしたら改竄になる。

でも「実験ノート」をそのまま貼り付けただけでは「科学論文」にはならない。論文では必要な情報だけを抜き出し簡潔にまとめて他人に分かり易く説明する必要がある。
そのためには何度も推敲する必要があり、手元にある論文の原稿は何度修正しても良い。改竄とかじゃない。

あと一度出版された論文の内容は修正できない。訂正するには新しい論文を書いて指摘する必要があるあたりも同じ。

意外と長文になった。すまん

2022/11/18(金) 19:01:59.21

meta版のgitもどきが出たことで
終わったのはgitじゃなくて
長文おじさんの方だったというオチ

2022/11/18(金) 19:43:38.39

>>324
俺もそう思うがそこはモノレポの限界なんだろ。

全てをありのままに記録するとbranchが煩雑すぎて余計意味分からんから、
いっそのこと熊手形状(ある点までは幹は一本でその先は一斉に分岐)に強制した上で、適用順に幹に追加、ということだろ。
幹は縞々模様になるが、一本鎖にはなるし、拡大すれば子細も得られ、縮小すればあらすじが得られる。
まあ初手としては悪くない選択だと思うよ。これまでのログを見慣れてる奴にも馴染みやすい。

そしてこの場合、rebaseをユーザーから隠蔽出来るから、(というか多分これが目的)
実際はありのまま全部記録してたが(M)、表示では一本鎖にしてました(V)、なんて事もツール内側だけで出来る。
だからsapling方式でユーザーは全く問題ないと分かったら、次手としてMVC分離で今君が言ってる事(＝俺が欲しい機能)もやれる。
ここら辺の作戦は、実用主義で良いと思うよ。ツールは、
・「今出来てない」ことが出来ないのは、大して問題にはならないが、
・「今出来てる」ことが出来なくなるのは、大問題だから
ユーザーからrebaseを本当に取り上げて良いかをまず様子見して、というわけだ。
(この点、ダイレクトにこの次手を目指すべき、と思う連中には物足りないだろうが、
作ってる連中が自分達のモノレポ用にチューニングしてるのだから、まあ仕方ない。
ただGitにはMVC臭がまるでなく、おかしな仕様になってる部分をmetaが修正してくれることには期待だ。
rebaseはViewでやるべきで、Modelでやるのは不味いし、基本にも反する。
ここら辺の判断が付かないのだから、Git開発陣はMVCを知らないのだと思うんだよね。つかあいつら色々不勉強すぎ)

ただ、根本的な問題は、今のGitは一次元(時間軸)方向に成長する「一つの」ものをトラッキングする用に出来てて、
モノレポみたいに「多数の」物をブチ込んだ場合に対応出来ないことだ。
モノレポの場合は成長方向が多数だから、例えば中央から外側各方向に成長するものであって、
記録としては年輪やレーダーチャートみたいな見え方にならないと駄目だが、少なくとも今のGitはそうなってない。ただの線だ。
(それはポリレポでやれ、なのだろうけど、適度に癒着してるからモノレポの方がいいという判断なのだろうし)

2022/11/18(金) 19:44:10.39

>>329
それは紙媒体前提の、20年前の思考だよ。
実際Gitはそうだけど。

2022/11/18(金) 20:19:37.39

>>332
「紙媒体」ではなく「分散・非同期」でやる手続きな。git と科学研究の共通点。
「集中」とか「完全同期」とかの管理型が好みなら別の手順になる。

2022/11/20(日) 08:24:46.99

>>166
長文君がソフトを作る話はまた「いい名前を思いつかないから先延ばし」？

2022/11/20(日) 09:16:26.61

立てた。

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

>>334
つかお前らマジのニートなんだと思うが、
今日やれ明日までにやれ今すぐやれ、とか、仕事はそういうものではないんだよ。
何であれ段取り良くしようと心掛けるのは大事。
というかそういう努力をしないと出来るようにはならないから、Gitに頼り切ってると上達しないのだと思うよ。今の君らがそれ。

ちなみにLinusがC++erを嫌ってるのは、
C++コンパイラがよしなにやってくれることを何も関知せず、C++なら素晴らしいと盲目的な連中が多いからで、
当たり前だがC++コンパイラが何やってるか理解してればそれをCで手動で書くことは(面倒だが)可能で、これを要求してる。
本来ツールはこのように、「無くても出来るけど、手間を減らす為に使う」のが正しく、
ツールがないと何も出来ない(C++コンパイラがやってくれないとメモリ管理も出来ない）連中が使うべき物ではないんだ。
Gitで凄く楽になった、が正しく、Gitが無いとプログラミング出来ません、は完全に間違い。
これはGit以前はそれなりに「手動で」段取り良くやらないと収拾がつかなかったからだけども、
ここでツールに頼り切って段取り良くやることを放棄しては駄目だ。
(と思うがGit陣営はこれで回ってるからなあ。
でも上達はしてない。ただこれも、Git以前の上達＝段取りが良くなる、に近いから、
Gitがあれで最終的に破綻しないのならあれでいいのだ！になってしまうし、なんだかねー)

2022/11/20(日) 11:39:05.33

相変わらず適当なこと書いてるな

2022/11/20(日) 14:18:59.87

git使うと段取りが良くなるからみんな使ってるんだけど、長文君はそうじゃないみたいだな

2022/11/20(日) 15:01:25.69

git はプログラムした結果を共有するためのツールって延々書かれてるのに、都合の悪いことは無視するよな
それとも理解できないほど馬鹿なんだろうか

2022/11/20(日) 15:19:13.23

ルールさえ決めておけば物置になるだろ。

2022/11/20(日) 15:47:31.91

>>335
>御託を並べるのは長文君ソフト(仮)を完成させ、それがgitよりも
>使われるソフトになってからにしろ

ってことで、大口叩いてるのではないことを示すために進捗状況を
公開しろと言ってる
スレは立てたけどこうなるんだろ

>言うだけでやらない理由を長々と説明（）しはじめそう

2022/11/20(日) 16:14:31.73

gitも満足に使えない奴ら向けのバージョン管理ソフトを作るってことはGit以上に開発に時間かかるだろうけど、本当に来年の3月までに一人で完成させられるのかな

2022/11/20(日) 17:06:14.30

>>340-341 せっかく別スレが立ったんだから、こっちで触らないで欲しい。

2022/11/20(日) 17:13:04.64

同意
ようやくGitスレに静寂が訪れた

2022/11/20(日) 17:37:52.87

>>342-343
すまん

>ようやくGitスレに静寂が訪れた

そうなるといいな

2022/11/21(月) 18:06:16.47

ふと思ったんだが

・リモートブランチを削除して再度push（git push --delete + git push）
・リモートブランチに強制push（git push -f）

て一見やってること同じだけど違うことしてるのかな

2022/11/21(月) 20:16:54.04

>>345
追加のオプションによって動作が変わるので厳密には違うけど、原則似たようなもんだよ

2022/11/22(火) 12:50:44.41

ワクチン接種歴「4回目までしか入力できない仕様」 - HER-SYSの接種歴回数、5回目は「不明」に

DSCIA自民
ネオコンウヨスパイは見つけ次第射殺しろ！
WHOロックフェラーを討伐せよ！

コロナで死んでいない人　99.96％　厚生労働省発表　

コロナ死者数のカウントはコロナ以外で死んだ人をコロナで死んだこととし
ワクチンを打たすため誘導した洗脳報道

裁判で名前を呼ばれる間抜けロックフェラー

コロナ対策に関する『大陪審（grand jury）』の審理を開始★ ライナー・フーミッヒ博士の冒頭陳述
https://www.bitchute.com/video/lZH4HZjO6QJE/

2022/11/22(火) 22:08:00.97

いい歳こいて反ワクチンて

2022/11/23(水) 03:18:59.26

時を同じくして今、海外でも長文ガイジ理論が熱い！
分岐もマージもせずひたすら一本道のコミットが続く方法論が大人気！
https://westling.dev/b/extremely-linear-git
この記事に対するHacker Newsのスレでも驚愕を持って迎えられ議論白熱「思いもつかなかった」「世紀の大発見だ」「天才か！？」など大絶賛！
https://news.ycombinator.com/item?id=33704297
今、世界でバケツが熱い！
ちなみにGitHubのページはこちら
https://github.com/zegl/extremely-linear

2022/11/23(水) 04:03:37.04

>>349
お前が持ってきた最初のリンクの内容を翻訳してやるよ。ヴァーカ

> 非常に直線的な Git の歴史
> 私が自分のプロジェクトでやりたいことの 1 つは、git の履歴をできるだけ直線的にすることです。
>
> 通常、これはコミットをメインブランチにリベースすることを意味しますが、
> フィーチャーブランチからメインへの一方向のマージのみを許可し、
> その逆は許可しないことを意味する場合もあります。それはプロジェクトによって異なります。

2022/11/23(水) 04:11:32.20

>>350
バカだなぁ、もっと先まで読めよ早漏ｗ

2022/11/23(水) 09:13:29.19

>>349
ビットコインかよｗ

2022/11/23(水) 15:17:09.85

shit!!!

2022/11/24(木) 19:40:50.83

Git v2.39.0-rc0

2022/12/01(木) 09:13:28.57

Git v2.39.0-rc1

Junio氏復活してるね

2022/12/03(土) 15:58:06.16

.gitmodules で commit-id やタグが指定できないのはなんか理由があってなのかな。
技術的にそう難しそうにも思えないが。

2022/12/04(日) 02:42:11.35

>>356
urlの代わりにコミットID書くってこと？何のために？

2022/12/04(日) 09:44:56.48

代わりにじゃなくて併記でそのurlのリポジトリの特定のコミットを指定できたらいいと思った。
過去のバージョンをチェックアウトした時、参照先の最新と互換性がない場合なんかは困るんでないかな。

2022/12/04(日) 14:21:46.42

>>358
urlが指すリポジトリを取ってきてそこでcheckoutするコミットは最新のものではない
checkoutするコミットは.gitmodulesじゃなくて別の場所に既に記録されている

2022/12/04(日) 14:24:37.72

具体的には、コミットグラフの中で、通常のディレクトリは treeオブジェクトのハッシュが記録されているけど、
サブモジュールが展開されるディレクトリは別リポジトリの commit オブジェクトのハッシュが記録されている
cat-file -p とか使ってコミットグラフのtreeを辿って行けばサブモジュールはtreeじゃなくてcommitになっているのがわかる

2022/12/04(日) 14:59:06.51

なるほど、commit-id はリポジトリに記録されているのか。ありがとう。

2022/12/06(火) 18:27:07.29

Git v2.39.0-rc2

2022/12/11(日) 15:35:02.81

Git v2.38.2

メンテナンスリリース

2022/12/13(火) 00:47:30.62

Git v2.39.0

2022/12/16(金) 16:40:26.39

おもしろかったので

Gitは最初1244行しかなかった
https://zenn.dev/uta8a/articles/b7169fd147fb31

**デフォルトの名無しさん** (JP 0H27-ZR1D) · 2022/12/19(月) 18:06:02.84

Githubのブラウザ上でmaster派生の新しいブランチを作ってプルリクを作ろうとしても
「there isn’t anything to compare 」と出て作れない

masterと新しいブランチに差分がないからだと思っていてローカル環境だと空コミットうって差分を作るんだが
Githubのブラウザ上からでも空コミットでできるの？

個人のリポジトリならReadMeとかの内容を適当にかえて差分を作るんだけど
そうじゃないケースだと空コミットで済ませたい

2022/12/19(月) 18:13:54.82

そもそも差分がないプルリクって何がしたいの？

**デフォルトの名無しさん** (JP 0H27-ZR1D) · 2022/12/19(月) 18:21:38.58

あとで特定の目的をもったブランチ群をマージするための受け皿となるガワが欲しいんだってさ
そのガワに集めてからmasterにマージする

2022/12/19(月) 18:30:50.92

あーなるほど、それは分からんでもない
GitHub Actionsで空コミット作るだけのワークフロー作ってworkflow_dispatchで手動トリガしたら

2022/12/19(月) 18:50:59.00

役に立つ回答では無いと思うけどgitlabだとできる

2022/12/20(火) 19:19:14.78

基本機能でさくっとできれば理想だったけど、そうはうまくいかないのね

2022/12/20(火) 19:42:20.28

そもそもプルリクエストはgitの機能じゃないしなぁ

2022/12/20(火) 19:52:26.33

GitHubのプルリクエストが今の仕様なのは、むしろGitが想定している本来のワークフローを尊重した結果じゃないか？
プルリクエストって本来は文字通り俺のリポジトリからプルしてくれというメッセージ機能に近いもので、
この例のように組織内でのブランチ間の差分のモニタリングを目的として使用されるなんて当初は考えもしなかったんだろう

2022/12/21(水) 00:42:11.62

「Gitea」の開発者が離反、代替プロジェクト「Forgejo」を立ち上げ
https://codezine.jp/article/detail/17071

Gitリポジトリマネージャがどこで使われているのか、よく分からん。

2022/12/21(水) 08:24:55.62

>>374
ウチで使ってるわ
乗り換えないとならんのかなぁ

2022/12/31(土) 11:16:52.35

今年最後にgitを覚えようと
git 本体とtortoisegit と githubに登録したんだが

これ全部、機能としては同じだけど別物なのか？
あちこちのサイト見ながらやると「こっちのサイトはgit入れてて、あっちはtortoisegit 、こっちはgithub」
みたいな感じになって混乱した

2022/12/31(土) 11:19:54.01

githubを直接触りたいならgh cliのがいい
ghとgitの組み合わせが最強

2022/12/31(土) 11:31:53.96

git_tutorial (フォルダ)
└sample.txt

1.このフォルダでリポリトジを作成して、sample.txtに aaaaa と打って comitした
2.sample.txtの中身 aaaaa を削除し bbbbb と変更して２回めのcomitを行ってみた
3.powershell 上で git log をすると２つのcomitを確認できる

この状態で最初のコミットのファイルを利用するにはどうしたら良いの？

2022/12/31(土) 11:44:42.71

そもそもブランチから勉強した方がいいのでは？

2022/12/31(土) 11:51:33.96

>>379
ブランチがどうこう、ってのはわかるんだけど具体的なやり方がわからない
ブランチをすると手元のフォルダのsample.txtの bbbbb が aaaaaにもどる
ということではないのか？
sample.txtの別ファイルが作成される感じ？

2022/12/31(土) 15:05:58.44

git log #ブランチ名・コミットIDを確認
git checkout <コミットID> #過去のコミットに戻す
git checkout <ブランチ名> #最新の状態に戻す

その様子じゃ次から次に質問しそうだから一度ドキュメントに目を通した方がいい
https://git-scm.com/book/ja/v2

2022/12/31(土) 23:11:48.42

セレじょは5人3D揃ったからいよいよ3Dコラボの年だよなあ
ちぐちゃんには頑張って欲しい

2022/12/31(土) 23:12:03.45

誤爆誤爆

2023/01/01(日) 01:04:33.92

376にOS 質問する人いないが、俺も聞いてやらない

2023/01/01(日) 02:07:20.13

powershellって書いてるじゃん

2023/01/01(日) 02:17:53.54

>>385
最近は linux 用の powershell とかあってな。
（ひねくれたツッコミをしてみる）

2023/01/01(日) 02:29:40.05

>>384
tortoisegitの時点で一個しかないだろ

2023/01/01(日) 03:11:58.02

>>385-387
みんな親切過ぎだろ。
長文くんを思い出せ。

2023/01/02(月) 20:37:53.17

MLに
"Request to remove Junio C Hamano as the Git Maintainer"
（濱野純をGITメインテナーからクビにする要求）

と言うメールがFilip Lipienという人から年末投稿された。
https://public-inbox.org/git/Y7JRh6WZ1YZ2AkKJ@mit.edu/T/#t

------------Google翻訳
Git の使用に関する Stackoverflow に関する質問は 100 万件以上あります。
これは正常ではありません。

Git は現在の状態では、人間のために作られたツールではありません。

彼が開発者の経験を知らなかったために、何百万時間もの作業時間が無駄になったと考えるのは現実的です。
経済的損害は数十億にのぼります。

Junio C Hamano 濱野純氏を Git メンテナとして解任するよう要請します

2023/01/02(月) 21:01:16.13

長文くんを思い出す

2023/01/02(月) 22:02:14.30

ながふみ君?

2023/01/03(火) 00:38:48.69

直後のTedさんのリプライがおもろかった。
濱野さんが何をしたのか、何をしなかったのかがさっぱり分からんのだけど、
長いスレッド読んでくと書いてあるのかな？
読んだ人いたら教えてw

2023/01/03(火) 01:27:53.62

機械翻訳で見たけど、件数だけみて文句があるアホなPMみたいなのが吠えて、それだけ。
Incorrect. As of this writing, there are 146,090 quetions[1] tagged

管理者機能とユーザ機能と分かってないだろうとか言われてるし、濱野さんは気を悪くしないように気付かわれてる。

大半の人は、GitHub から入門して、お仕事の人も GitHub が多いと思うから GitHub に不満がある気がするけど、どうなんだろ。

2023/01/03(火) 01:44:58.77

それは全く逆で、むしろGitHub使える環境の人はGitに対してもGitHubに対しても満足度高いと思うぞ
Git使ってるのにGitHub使ってないというのはだいたい下請業務など劣悪な環境だろうから、Gitに対してもヘイトが集まることになる

2023/01/03(火) 05:34:05.62

ワイはgitには特に何もないが、GitHubには文句たらたらや

2023/01/03(火) 07:04:51.47

マイクロソフトがー、マイクロソフトがー

2023/01/03(火) 17:51:22.90

おまいら、ギフハフって灰汁の組織知ってるか？

2023/01/15(日) 11:41:44.14

ギフハブだぞ
AS*Aさんのセンスでギフハフなんて響きの悪い名前を思いつくわけないだろ

2023/01/18(水) 08:55:28.93

Git v2.39.1 and others

2023/01/20(金) 11:58:28.71

「Git」に3件の脆弱性～修正版のv2.39.1が公開 - 窓の杜
https://forest.watch.impress.co.jp/docs/news/1471256.html

2023/01/22(日) 00:10:04.98

stalmannenってスェーデン語でSuperMan のことなんだって。
だから、あの左翼は頓珍漢なことばかり言ってたのか。

2023/01/23(月) 08:39:01.26

ちょっと教えてください。
a、b、c、d、eとコミットして
bにリセットしたらcdeの修正分はなくなるよね？
最初の状態からcをリバートしたらdのコミット分だけが無くなる？

この時cの修正に依存するd,eの改修箇所はエラー吐きまくるであってますか？

実際のチーム開発でrevertとかそんな使う機会ある？

2023/01/23(月) 08:47:04.02

>>402
ごめん
最初の状態からcをリバートしたらcのコミット分だけが無くなる？
です

2023/01/23(月) 09:17:09.28

>>402
pushしたならrevertしかないから、使ったことはある
>>403
その認識で合ってる

2023/01/23(月) 10:00:41.12

>>404
ありがとう。
cの修正に依存するd,eの改修箇所は
手動で調整するしかない？
だよね？

2023/01/23(月) 10:08:15.27

revertは実際のチーム開発では主にリリース直前や直後に戻すときに使う
途中のコミットだけ戻すのも、リリースにむけて成果をマージしていくメインストリームのブランチの場合は珍しくない
例えば、各自の作業をmainブランチに統合した後にステージング環境で最終確認してて特定の新機能に不具合が見つかったら、その機能のマージコミットだけをmainブランチからrevertしてリリースする
一般的にはそういう統合用のブランチにおいてそれぞれのマージコミットにはあまり依存関係がないから、途中のコミットであっても安全に戻せることが多い

2023/01/23(月) 10:51:47.46

>>406
ありがとう。参考にシマス。

2023/01/23(月) 17:43:30.01

>>405
deだけを付け直すrebaseのオプションがあったはず。ブランチ切らないとダメかもしれないけど

https://git-scm.com/book/en/v2/Git-Branching-Rebasing

これの more interesting rebasesのところ
日本語版もあると思うので読んでみてくれ

2023/01/24(火) 14:12:59.02

>>408
ありがとう。読んだけど脳みそのキャパオーバーぎみ。
マージと同じような意味でリベース使えば履歴がスッキリするよって感じなのかな。

2023/01/25(水) 18:58:25.67

GitHubでフォークされた場合にフォークリポジトリを削除してもらう方法ってフォーク主にお願いするしかないんですか？

2023/01/25(水) 19:26:11.38

いいえ、フォーク主にお願いしても削除できません

2023/01/25(水) 19:33:00.95

>>411
そういう仕様ですか？

2023/01/25(水) 19:37:07.29

フォーク主にお願いしただけでは削除されませんっていう重箱の隅

2023/01/25(水) 19:50:29.62

フォーク自体は削除できるのでフォーク主にお願いして削除してもらえばいいと思うのですが
現実問題としてそれで削除してもらえるのかという問題はありますけど
他にいい方法ないですかね？

2023/01/25(水) 21:01:54.27

個人情報うpしちゃったとかなら
GitHubのサポートに削除してもらえるかも

フォークした奴がお願いしてもきかなくてまたpushしたりした場合は知らん

APIキー漏らしたとかなら
悪用される前にAPIキーを無効化して作り直すべき

2023/01/25(水) 22:32:00.35

そもそもgithubの話題はスレチ

2023/01/26(木) 21:19:38.08

じゃあどのスレならいいの？

2023/01/27(金) 02:39:06.99

githubとかのスレ落ちてるね

2023/01/27(金) 02:41:24.15

1000まで使い切って落ちたみたいだから次スレたてようか
前スレがOSSホスティング総合からｿｰｽｺｰﾄﾞﾎｽﾃｨﾝｸﾞ総合に名前変えた1スレ目だったから、次スレをｿｰｽｺｰﾄﾞﾎｽﾃｨﾝｸﾞ総合の2スレ目にして立ててしまおう
ちょっと長いからスレタイからbitbucketは退場してもらう「ｿｰｽｺｰﾄﾞﾎｽﾃｨﾝｸﾞ総合 2【GitHub,GitLab等】」で

2023/01/27(金) 02:50:50.96

立てた

ｿｰｽｺｰﾄﾞﾎｽﾃｨﾝｸﾞ総合 2【GitHub,GitLab等】
http://mevius.5ch.net/test/read.cgi/tech/1674755161

次のGitスレの1にもこのリンクなるべく貼ろう
githubの話題はこっちにって

2023/02/15(水) 08:49:46.98

Git v2.39.2

2023/02/19(日) 15:35:48.54

.gitignoreに
supervisord*
と記述していて
supervisord.log
supervisord.log.2
supervisord.log.3
supervisord.pid
は除外されるんだが
supervisord.log.1
だけ除外されない。これなんで？

2023/02/19(日) 15:41:46.42

どうせ誤字だろ
>>422をコピーして各行の頭にtouchつけてファイル作成したけどちゃんと全部除外になったぞ

2023/02/19(日) 15:42:44.58

誤字する余地ある？
つーかそのままコピペしたんだけどどこか間違ってる？

2023/02/19(日) 19:10:19.28

.gitignoreに記述する前にそのファイルだけaddしてたとかコミット済みだったとか？

2023/02/22(水) 14:17:17.89

TortoiseSVNは内部にSubversionの機能を持っていてましたが、TortoiseGitとGitは別れていて、
TortoiseGitとGitは別々に自分でアップデートしなくてはいけないということで合ってますか？

2023/02/22(水) 14:34:18.81

あってるよ
TortoiseGitは単なるシェルエクステンション