Git 18

2022/04/23(土) 03:25:45.27

ソースコード管理を行う分散型バージョン管理システム、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 16©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1502726047/
Git 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2022/07/24(日) 17:27:34.93

うるせー馬鹿野郎

**370** (ﾜｯﾁｮｲ b15f-KxVo) · 2022/07/25(月) 04:35:51.61

>>371-372
ありがとうございます理解できました
>>373
試してみましたがリモートのブランチを指定しないとだめみたいです

origin/dev と origin devは別物でしょうか？
前者をリモート追跡ブランチとして認識しておりますが

**375** (ﾜｯﾁｮｲ b15f-KxVo) · 2022/07/25(月) 04:44:01.07

訂正です。
引数にorigin/devを指定するとダメで、origin devならOKということがあるので
origin/dev と origin devは別物であるような気はしています。
いくつかコマンドを実行してみて得られた結果から推理したイメージは
①リモートのdevブランチと最も近い位置にあるローカルのブランチがorigin/dev
②リモートのdevブランチを指すのがorigin dev
といった感じです。

git logをした時に確認できるorigin/devは①のorigin/devと同一であり、これがリモート追跡ブランチだ
という理解であっておりますでしょうか。

2022/07/25(月) 09:09:50.38

origin dev はローカルの dev ブランチが追跡している「リモート」のブランチ。
origin/dev はそれの「ローカル」コピー。コピーは最新ではない可能性がある。
という言い方をすると良いのかな。

2022/07/25(月) 09:32:52.93

正確に言うと違うのでややこしいな。順番が逆というか。必ずしも origin じゃなくても良いとうか。

2022/07/25(月) 10:07:23.18

リモートリポジトリは、origin以外を使ってみたり、ファイルシステム経由でベアリポジトリを使ってみたりすると理解が深まるね。
インターネット接続不可能な環境だと結構使う。

2022/07/25(月) 23:35:48.37

>>375
別物っちゃ別物だけど。
gitのヘルプを読んだほうがいいよ。
端的に言えば、origin/devは通常、リモート追跡ブランチと言っていいもので、origin devはコマンドに付けた2つの引数。

mergeはローカルレポジトリにあるrefとマージするもの。
fetchやpull(pullはfetch+mergeだから、以下fetchのみ説明する)は、リモートレポジトリにあるrefを、ローカルレポジトリにコピー/ダウンロードしてくるもの。

refは"コミットを指す参照"のこと。
つまり、refはローカルブランチ、リモートブランチ、タグなどのこと。
よく言われるように、ブランチやタグは、コミットへのポインタであるから、refはコミットを指す参照と言った。
refは、各々のレポジトリにルートにある.git/refs/**が実体。(以下.git/を省略)

refはすべてレポジトリごとに保存されている。
git branchコマンドなどでローカルブランチを作ったり、fetchやpushでリモートブランチを作ることができる。

2022/07/25(月) 23:37:25.77

>>380
リモートブランチという名前だけど、特定のレポジトリ(例えばorigin)のrefを、ローカルレポジトリにコピーしたもの。
リモートレポジトリoriginからfetchをすると、originにあるrefs/**をダウンロードしてきて、ローカルファイルシステムに、refs/origin/**として保存する。

fetchをしなければ、最後にダウンロードしたときのままで、リモートレポジトリが他人によって更新されてても、refs/origin/**は自動には更新されない。

いつもrefs/を付けるのは面倒だから、これは省略できる。
ローカルブランチの実体.git/refs/heads/branchAは、branchAのみで通常呼ばれる。
リモートブランチの実体.git/refs/remotes/origin/branchBは、origin/branchBのみで通常呼ばれる。

2022/07/25(月) 23:38:28.96

>>381
merge branchAは、merge refs/heads/branchAの省略形で、後者で書いてもマージできる。
refsであればマージできる。
上に書いたように、refsはリモートレポジトリからコピーしてきたもの(origin/...)と、自分で作ったref(ローカルブランチなど)のことだから、
merge branchAでも、merge origin/branchBでも正しい表現。
そのときそれらが指しているコミットとマージする。

2022/07/25(月) 23:39:16.54

>>382
fetch origin devは、fetch origin refs/heads/dev:refs/remotes/origin/devの省略形で、後者で書いてもfetchできる。
これは、originにある.git/refs/heads/devを、ローカルレポジトリの.git/refs/remotes/origin/devにコピーするということ。
だから、fetch origin develop:devと書けば、originのdevelopを、ローカルにdevという名前で保存することも可能。
ただしトラッキングブランチの設定がある場合は、もう少し前処理が入る。(説明が冗長になるので省略。ただし、ほとんどの場合はリモートトラッキングの設定しているはず。)
ここで、fetch origin/devと書くことが何をしているかは分かりますか？
何を省略しているかを考えれば想像できると思います。
答えは書きませんので、自分で実験するなり考えてみてください。
(普通このコマンドは失敗します。そのようなrefを普通は作らないからです。)

ちゃんと知りたければ、自分でヘルプ読んだほうがいいよ。
push, fetch, pull, refspecなどを読んでみて。

2022/07/25(月) 23:48:16.63

>>383
誤記あったので訂正。
> fetch origin/devと書くことが
→ fetch origin origin/devと書くことが
以上。

ちなみにfetch origin/devは必ず失敗すると思います。
その位置にはrefではなくてリモートレポジトリ名を書くわけだが、origin/devってい名前は作らないと(多分作れない)思うので。試したことないけど。

2022/07/25(月) 23:59:56.84

refspec使った例で、自分がたまにやるやつを紹介して補足すると、
pushの例になるけど、
git push origin @~2:developとかは使うかな。
update update ...っていくつかコミットしたあとに、2つ前までのやつならちゃんと作れてるから、それをpushしておこうなんてときに。
fetch方向だとそういう工夫は必要ないと思うから、追跡してるとおりに取ってきちゃうけど。

2022/07/26(火) 00:11:33.45

あと、上にorigin以外を...って話があるから、自分のユースケース紹介しておくと、
自分だけが使うようなコンフィグファイルの設定とかを、backupっていうリモートレポジトリの名前で、別のフォルダに向けておいて、
git push backup myconfig1とかやることあるかな。

この場合は、リモートブランチとしてbackup/myconfig1っていうのが作られるよ。
リモートレポジトリはoriginだけじゃなくてもよくて、
ローカルレポジトリに、backup/myconfig1はorigin/developと共存してる状態だよ。
ごめんね、自分語りが長くて。

2022/07/26(火) 12:40:11.27

gitクライアントからボタン一つクリックするだけで完了するような操作を、いちいちターミナル立ち上げてタイプしてる人は何？
しかもタイピングが遅いからまどろっこしくて仕方ないw

2022/07/26(火) 15:46:31.59

>>387
コマンドでgitを使う=タイピングが遅い
決め付けの激しい人だな

2022/07/26(火) 16:14:03.11

そもそも普段からキーボード打つ方が、何十倍も早いだろ。煽るにしてもレベル低すぎ。
それともマウスでプログラム組んでるとか主張するんだろうか？

2022/07/26(火) 17:29:56.27

>>377
origin/devはgit logで表示されるorigin/devと同一という理解であっていますか？
であれば、git logをした際にdevブランチの方がorigin/devよりも上（新しい）に表示されることがあるので
必ずしもorigin devのローカルコピー版であるorigin/devは最新ではないという説明には納得がいきます。

>>381
冒頭に書いてあることは、リモートブランチもリモート追跡ブランチと同様に、ローカルリポジトリ上に存在するという理解でよいですか？

2022/07/26(火) 17:53:40.65

>>388
そうとは言ってないだろ
文書が読めるようになってからレスしろよ

2022/07/26(火) 19:18:08.90

「タイピングが遅い」っていうのは自分のことを指していってるんじゃないかなぁ
たぶんある種の自虐かと

2022/07/26(火) 19:34:51.51

いやよく読もう

> いちいちターミナル立ち上げてタイプしてる人は何？
> しかもタイピングが遅いからまどろっこしくて仕方ないw

タイピングが遅いはどう考えても一般論じゃないんだから、身近にそういう変わった人がいるという質問風の愚痴だろ
「ほーん、で？」「それは大変だったね」「しらんがな」とか答えてあげるかスルーすればいい案件

2022/07/26(火) 19:38:48.45

特定の誰かがタイピング遅いから全員gitコマンド使うなという主張だよ

2022/07/26(火) 19:42:06.64

被害妄想じゃね

2022/07/26(火) 19:43:23.18

いちいちターミナルを立ち上げって書いてあるけど、普通ターミナルなんて立ち上げっぱなしだよなあ

2022/07/26(火) 19:49:04.16

開いてあるターミナルでコマンド履歴を呼び出したり git switch - 打ったりはコマンドが早いな
エイリアスがあればさらに早い

そのタイピングが遅い人はgitの練習かタイピングの練習がしたいんじゃね

2022/07/26(火) 19:56:26.38

>>390
はい。わたしは>>381には、リモートブランチとリモート追跡ブランチが同じ意味で書いてます。

前半は自分にはわからなかったです。
どのorigin/devが、logのorigin/devと同じと言っているんだろう。
origin/devは普通.git/refs/remotes/origin/devの省略形として使われるのであって、
git logの引数の説明に、refspecとかrevisionとか書いてあったらそうだろうと思います。
自分はそういうつもりで使ってますが、ちゃんと知りたいなら調べてみたらどうでしょう？
文脈によっては.git/refs/heads/origin/devかもしれないですね。これは難癖ですが。（つまりorigin/devっていう名前のローカルブランチ。でもコマンドミスで、たまに作ってしまう…）

2022/07/26(火) 19:59:34.56

>>398
話が長くてすまんが、要はorigin/devはなにかの省略形で、それは文脈によって決まるということです。
origin/devっていったら、普通はアレのこと、というのはありますが、一つの言葉に固執している様子を感じたので、原著に当たったほうがいいよというアドバイスになります。

2022/07/26(火) 20:52:33.24

>>399
ああ、そういうことですか。腑に落ちました。
仰るとおり、一つの言葉の意味を一つに定めようとしていました。
origin/devといっても脈絡次第でそれが何の略であるか、いくつか解釈パターンがあるんですね。

原著はgit-scm.com/docｓ/であってますか？
tagやcommit等を調べるときはこのページを利用しました。
このスレの皆さん、リモート追跡ブランチが何であるかを理解した時も原著を参照されたのですか？
書籍等でわかりやすく日本語でまとめられた情報等は購入されていないのでしょうか？
参考までに教えて頂けると助かります。本当は自分でわからないことをすべて調べられるのなら理想なのですが
まだその段階には至っていないようです。

2022/07/26(火) 21:27:22.81

>>400
用語はそのurlからgitglossaryで検索すると見れます。
というか、コマンドラインからgit help gitglossaryで、使ってるバージョンのヘルプページが開きます。
この中を、remote-tracking branchをページ内検索すればリモート追跡ブランチの説明があります。

あと、git help gitで、使えるコマンドの大枠が見れます。

本については、10年以上前ですが自分はjunio c hamanoが書いた本で学びました。日本語です。その後3冊買いましたが、最初ので十分でした。
オンラインで無料で読めるやつならpro gitが一番読みやすいと思います。日本語訳があります。
ただしこれはツールとしての使い方が主です。

2022/07/26(火) 21:35:13.51

>>401
ProGit後半の方には内部実装に踏み込んだ説明もあるので、あなたの知りたいことは、こちら寄りかもしれません。
多くの人は、ツールを一般的なユースケースで使えればいいのであって、origin/devとorigin devはどう違うのか、といった疑問は感じないか、もしあってもすぐに忘れます。

origin/devとorigin devの違いだけを知りたい場合はすでに説明したとおりです。
でも更に疑問が出てくると思います。

あなたの疑問は、定義をしっかり知ったほうが理解につながるものだと思うので、地道にヘルプなどのドキュメントをたくさん読んで、自分の頭で探し方を学んだほうがいいものだと思います。

2022/07/26(火) 23:28:02.96

commitはメッセージが改行付きで長めになるのでGUIでやってるｗ
status,checkout,push,pull,mergeみたいなのはコマンドラインでやってるなぁ

2022/07/27(水) 00:32:02.65

commitコマンド実行したときにエディタ立ち上がるようにしてないの？

**デフォルトの名無しさん** (JP 0H8b-kbwT) · 2022/07/27(水) 02:00:04.13

環境依存な話ですが、Macでターミナルからgit difftoolした時に外部diffビューアを立ち上げ
たいのですが、皆さんどうしてますか?

ググってopendiff (-> FileMerge)を呼ぶ設定にしてみたのですが、複数の変更ファイルが
あるとき、FileMergeが2番目以降のファイルを開いてくれません

2022/07/28(木) 16:17:00.66

呼び方が混乱してるのかも。通常の使い方だと、以下の通り。
origin dev 「リモートブランチ」、 origin という名前のリポジトリ上にある dev という名前のブランチ。
origin/dev 「リモート追跡ブランチ」、origin/dev という名前のローカルブランチ、上記のリモートブランチを追跡するように設定されている。
dev 「追跡ブランチ」、dev という名前のローカルブランチ、上記のリモート追跡ブランチ(origin/dev)が上流に設定されている。

（注:あくまでデフォルトなので変えることはできる…）

2022/07/28(木) 16:29:18.98

ターミナルにコマンド入力してのがかっこいいと思ってる人いる？

2022/07/28(木) 17:09:52.93

>>407==>>387
どんだけコマンド敵視してんだよ

2022/07/28(木) 17:16:34.57

>>407は凄くかっこ悪い

2022/07/28(木) 18:31:06.84

煽り耐性なさすぎだろ…

ところで origin dev というフレーズに意味があると捉えてるのいいのかな
単に<repository>と<refspec>を順に受け取るコマンドが多いだけで、origin dev と oringin/dev を同格の概念だと捉えるのは理解を妨げると思うんだが

2022/07/28(木) 19:32:20.12

>>410
厳密に言えば違うけど、どっちもブランチを指定しているという意味では同格だろ。
ローカルブランチと、リモートブランチを取るコマンドで引数の指定方法が異なると理解しとけば良い。

2022/07/28(木) 20:04:25.84

我流で変な理解をするよりも、上で丁寧にわかりやすく説明してくれてくれてる人が言うようにちゃんとヘルプ見たほうがいいと思うけどね
中級者と本当に詳しい人の差はそこで出ると思う
refspecとは何か、tree-ishとは何かを説明できるかどうかはポイントの一つだと思う

2022/07/28(木) 21:31:34.95

未だにSVNなんか使ってgit使ってないのはやばいなんて言う方がやばいなんて話題になってたんだけどgitに慣れた身からすると
ローカルでコミットできない、ブランチを気軽に切れない、もうそれだけであまりに不便だと思うんだけど、SVNユーザーはこれをデメリットと感じないのだろうか？

2022/07/28(木) 22:20:18.72

gitのことを知らないんだからsvnのデメリットにも気付かないよ

2022/07/28(木) 22:40:17.73

ドカタ開発はもっと理不尽なことがいくらでもあるからその程度は大した問題じゃないんだよ
VCS使ってるだけマシ

2022/07/29(金) 01:55:35.40

>>408
なんで敵視？

2022/07/29(金) 02:26:57.20

デメリットなんて気付くわけないさね
スマホを使ったことがない人はガラケーの劣る点に悩まないし、自動車がなかった時代に初の自動車を見てもこのヘンテコなカラクリ仕掛けが世界を変えるとは考えられない
保守的な人やいつも忙殺されて余裕のない人は損失回避バイアスによって変化のリスクを過大に見積もり現状維持を選ぶし
いよいよ心が老人になると自分の慣習や価値観を否定されたと感じて怒り出す始末

2022/07/29(金) 06:43:18.42

>>413
その2点に慣れてしまうともう戻れないよな
コーディング方法さえ変えてしまうほど便利

2022/07/29(金) 10:26:37.17

>>396
++
tmux最強

2022/07/29(金) 10:28:01.90

>>393-394
判りやすい

2022/07/29(金) 11:55:40.15

CVS使ってた現場で、コミット漏れによる先祖返りで障害が起きた対策として、下記の作業手順が定められた
1. 一切コミットすることなくソースの変更とテストとレビューを済ませる
2. 本番からソースをダウンロードし、ワーキングセットとの差分を取る
3. ワーキングセットを本番にデプロイする
4. CVSにコミットする
もはやバージョン管理とは何なのかと思ったね

2022/07/29(金) 12:45:43.04

>>421
ローカルとかチームではgit使って、サーバーだけcvsにした方が良さそうだな。

**421** (ﾌﾞｰｲﾓ MM9d-vZl0) · 2022/07/29(金) 13:13:28.48

あーちょっと不正確だった。正しくは、1の前に
0. 本番からソースをダウンロードし、CVSとの差分がないことを確認する
が入る。簡単に言えばVCSを一切当てにしないで本番環境にあるソースをマスターにしましょうってことだ。
こんなのCVSかGitかとかいう以前の問題で、ルール決める人間がVCSを理解してないんだからツールを何使おうが絶対に間違えるんだよ。
仮にGit使ってたとしても同じことになってるだろうね。

2022/07/30(土) 04:13:51.24

>>421
cvsがただのソース置き場になってるな
zip管理してるのと変わらん

それで回るのなら、cvsやめてzip管理でええやん

2022/07/31(日) 02:06:31.57

例えばgoogle trendで検索すると日本はgitに対するsvnの比率が世界最上位クラスに高いのが分かる
より良い技術を取り入れていこう勉強していこうってタイプの人が全然いないのかな
そんなものより動く製品作るのが大事だろ、知ってる技術使えばいいだろ、勉強する時間が無駄みたいな

2022/07/31(日) 02:15:39.82

>>425
すまん俺が svn 糞とかでググってるせいだわ

2022/07/31(日) 02:22:27.63

>>421
cvsじゃなくてtfvcだけどまさにそんな感じ
ブランチが開発差分じゃなくて、各モジュールを表すものになってるんだよねうち。メインに共通部品が置いてあるのよ
じゃぁこのブランチで開発してね他の人はいじらないから、みたいなこと最初に言われたとき、お前バージョン管理をなんだと思ってるんだってなったわ
>>424の言う通りだし、そもそも「バージョン管理」って概念自体がよく分かってない人結構いるのかもしれない

2022/07/31(日) 05:29:08.90

>>425
svnを敵視する人はこれだから困る

2022/07/31(日) 15:16:33.83

>>427
テンプレートからフォークしていく運用自体はそんなに珍奇ではないと思うよ
TFVCはよく知らないけどGitほど複数リポジトリに跨った管理が得意とは思えないから、
フォークの際にGitでクローンする代わりにブランチを使うのはまあアリなんじゃないか

2022/08/01(月) 09:23:36.02

Hamano氏のインタビューが載ってる　https://git.github.io/rev_news/2022/07/31/edition-89/

2022/08/06(土) 16:17:32.37

おまえらってgitを使ってなにを管理してんの？
どうせ人には見せれない、クソコードをprivateにして遊んでるだけだよなｗ

2022/08/06(土) 16:19:29.02

確かに見せられないな、機密情報だから
ごめんねー

2022/08/06(土) 22:54:01.88

恥ずかしくてみせないよな
ｗｗｗｗｗ

2022/08/06(土) 22:55:49.69

そんなにみたいなら見せてやるよ
最新作だ
https://github.com/NCNT/TimingCmds_in_POSIX/tree/main/c_src

2022/08/07(日) 06:13:33.06

相変わらずのダサいコードで笑う

2022/08/07(日) 10:36:56.12

>>434
なにこれ？
この程度ものを管理する必要があるのか？
しかも公開してｗｗｗｗ

やっぱり、偉そうにいうわりにはクソみたいなソフトしか作れないんんだろ

2022/08/07(日) 13:36:16.69

>>436
コミケで販売するから文句はそれ買ってから言え。通販もしてるぞ。

あなたのシェルスクリプトに正確な「時」をデリバリー
トキデリ Rich Mikan 著
https://richlab.org/coterie/tok.html

2022/08/08(月) 13:17:15.57

資源の無駄

2022/08/08(月) 13:28:32.63

githubの話はgitスレでしないでくたさーい

2022/08/09(火) 23:25:41.25

githubとgitは別物だぞ

2022/08/10(水) 01:11:45.77

>>440
gitを使ったシステムなんだから別物ではない

2022/08/10(水) 01:28:37.91

え？

2022/08/10(水) 02:07:21.61

DNAと人間は同じだから

2022/08/10(水) 02:47:33.52

repoってgithubとかgitlabみたいなもん？

2022/08/10(水) 07:15:46.58

>>444
ホスティングサービスではなくて、gitを補佐するクライアントソフトらしい
複数のリポジトリを一括で操作できるのが特徴とか
ライブラリが多いとか、扱うリポジトリが多いプロジェクトなんかだと重宝するかも

個人的にはいらんなぁ

2022/08/10(水) 07:45:39.95

自分も会社の業務以外でほとんど使用したことはないな
そもそも個人レベルのプロジェクトで複数のリポジトリ扱うことないし

Android SDKのソース落としてくる時に使ったぐらい

2022/08/13(土) 07:41:00.55

Git v2.37.2

2022/08/13(土) 19:37:20.99

個人レベルでgitを使う必要ある？
そもそも自分ひとりで書いてるなら大抵は覚えてるだろｗ

2022/08/13(土) 20:04:36.06

個人レベルだからこそ簡単に導入出来るgitを使う
別にリモートにpushやらしなくても所々コミットしておけば戻るのも簡単だし
便利だと思うのだけどね
ただバイナリ（excelのファイル)みたいなのには使わないが

2022/08/14(日) 02:14:02.08

新機能を実装する時は、変更前のソースを参照できるようにしておかないと面倒。

バグが発生したときは差分をすぐに参照できるようにしたいしな。

2022/08/14(日) 02:16:52.49

>>448
ローカルリポジトリだけでも完結できるのにgitをわざわざ忌避する理由がない

2022/08/14(日) 13:58:00.56

>>448
数万行のコードなんて覚えてられない
どうせおまえがやってるのは100行以下のサンプルコードだけだろｗ

2022/08/14(日) 15:10:31.19

>>452
どうせ公開できないんだろｗ
何とでもいえるわなｗｗｗ
俺なんてカーネル開発してるよ

2022/08/14(日) 15:48:56.36

>>453
たった数万行に驚いてるのか？

2022/08/14(日) 16:47:19.54

そもそも描いたこと無いからイキれるんだな

2022/08/15(月) 19:27:14.17

一日100行でも一年経てば20000行

2022/08/15(月) 20:10:11.85

svn脳の人はローカルリポジトリの概念がないからvcs使うことを大層に考えてしまうんだよな

2022/08/15(月) 20:22:20.12

リモートリポジトリが要らないというのは革命的だと個人的には思うけど、あんまりそういう話は出てこないよね。

リモートリポジトリ無しってgit登場時点で普通の話だったっけ？

2022/08/15(月) 21:27:50.09

リポジトリーのローカルコピーも含めてGitの機能的な部分はBitKeeperから持ち込まれたものだろ

2022/08/15(月) 22:34:37.88

>>458
SCCSとかRCSとか。

2022/08/15(月) 23:18:53.39

Gitの開発経緯を考えるとリモートリポジトリの存在はむしろ超大前提で、ローカルだけで使えるのは副産物みたいなもんでしょ
まあリモートと言ってもGithubみたいな中央集権型ではなくて、無数のリモートリポジトリがあってパッチを送り合うような開発スタイルが本来のGitの姿

2022/08/16(火) 01:17:15.07

https://ezoeryou.github.io/blog/article/2015-04-08-linus-git-interview.html
gitの10周年を記念したLinus Torvalsへのインタビューの翻訳

＞しかし、BitKeeperがやってきてからというもの、ソース管理に対する見方が変わったね。
＞ BitKeeperは大抵のことを正しく行っていた。
＞レポジトリのローカルコピーがあることと、分散マージはでかかった。

2022/08/16(火) 23:52:04.96

>>448
gitに限らんけど、VCSって個人レベルでも機能追加とバグ修正並行して進める時は楽だ

2022/08/18(木) 11:54:41.84

gitとgithubの区別がついてないんだろ

2022/08/25(木) 00:47:44.66

初歩的な質問になるけれど…
異なるローカルブランチ「debug」と「genbug」が存在する。
両方のブランチに全く等しい「iam.txt」と「whoyou.txt」いうテキストファイルがあって、
どちらのテキストファイルも両ブランチの最新コミット内に存在するものとする。
「Iam.txt]の中身は"I am a dog."

「debug」ブランチで【rm whoyou.txt】と打って「whoyou.txt」を削除し、「Iam.txt」の中身を"I am a cat."に変更してステージングをしないまま、
【git checkout genbug】と打って「genbug」ブランチに切り替え、ワークツリーを確認してみると、「Iam.txt」の中身は"I am a cat."に変更されているのに、
「whoyou.txt」は削除されていない（というより復活している）。
これはなぜなのだろうか？（whoyou.txtをgitリポジトリから消したいならrmコマンドではなくgit rm --cachedを使うべきなのはわかる）

いまいち、git checkoutをしたときのワークツリーの挙動が掴めない

2022/08/25(木) 02:38:58.44

「git checkout ブランチ」するとき、

checkout前のブランチにおけるワークツリー上でのファイルの編集や削除は、
checkout前のブランチにコミットされているそのファイルとcheckout後のブランチにコミットされているそのファイルが等しい場合、
checkout後のブランチにそのまま引き継がれる

つまりIam.txtが変更されているのは正しいが、whoyou.txtが復活するのは何か操作を勘違いしていると思う

ちなみに、
checkout前のブランチとcheckout後のブランチにコミットされているファイルが等しく無い場合、
checkoutすることでcheckout後のブランチにコミットされているファイルへ置き換わるが、
checkout前のブランチにおいてワークツリー上でそのファイルを編集や削除していると、
checkoutが失敗する

2022/08/25(木) 02:40:02.58

$ git status -sb
## debug
$ ls
iam.txt whoyou.txt
$ cat iam.txt
I am a dog.
$ echo "I am a cat." > iam.txt
$ rm whoyou.txt
$ git status -sb
## debug
M iam.txt
D whoyou.txt
$ ls
iam.txt
$ cat iam.txt
I am a cat.
$ git checkout genbug
M iam.txt
D whoyou.txt
Switched to branch 'genbug'
$ git status -sb
## genbug
M iam.txt
D whoyou.txt
$ ls
iam.txt
$ cat iam.txt
I am a cat.

2022/08/25(木) 10:19:53.57

>>466-467
whoyou.txtが復活するのは勘違いしていたみたいすまん
「checkout前のブランチにおけるワークツリー上でのファイルの編集や削除は、
checkout前のブランチにコミットされているそのファイルとcheckout後のブランチにコミットされているそのファイルが等しい場合、
checkout後のブランチにそのまま引き継がれる」
こんな仕様があったのか。知らなかった。ありがとう。

ワークツリー上で行った操作をなかったことにしたい場合「git checkout .」で良いと思うんだけど
ワークツリー上で行ったgit操作履歴（というかローカルリポジトリへのコミット内容との差分）を確認する方法ってないのかな

2022/08/25(木) 11:07:47.22

>>468
ワークツリーでの操作に関しては履歴は残らない
カレントブランチにコミット済みとワークツリーとの差分については、上でもやってるけどgit statusや、git diffでもできる

git diff # 差分の内容を表示
git diff --name-status # 差分があるファイル名とそのステータスを各1行で表示
git status # 差分があるファイル名を含めたワークツリーの状況を詳しめに表示
git status -s # 差分があるファイル名とそのステータスを各1行で表示
git status -sb # ブランチ名を表示した下にgit status -sと同じものを表示

2022/08/25(木) 11:08:10.42

git status -v
とかじゃダメなのか？

2022/08/25(木) 11:14:51.48

git status -vは-v無しと同じかな？
毎回git statusやると表示がうっとおしいので、git status -sbの方をシェル関数でgstに定義して良く使ってる
git status -vはmergeやrebaseが失敗したときに見る

2022/08/26(金) 18:45:49.38

たかだかpushするだけなのに、ターミナルからやった方がエモいですか？

2022/08/26(金) 19:07:22.83

エモいと言う言葉の意味がわからない