超個人的gitガイド

プロジェクト開始時

任意のディレクトリで

git clone ${GitHub_REPOSITORY_URL}

これによりリポジトリがまるまる複製された（正確には複製したうえで.gitが生成された）フォルダ（gitフォルダ）が生成される。
※GitHub上にレポジトリを作った後にこれをやらないでローカルでgit initしてしまうと「コードヒストリーが異なる」ので注意。
以降はなるべくこのフォルダの下で作業する。

自分の作業をGitHubに保存する/いわゆるpushする

git checkout -b ${BRANCH_NAME} #自分が作業するためのブランチを作成する git switch -cでもいい。
git status #ステージングエリアに反映されていない、変更されたファイルを確認 
git add ${FILE_PATH} #任意のファイルの変更をステージングエリアに反映する 
    #すべての変更を反映させるまでgit addを繰り返す
git commit -m ${COMMIT_MESSAGE} #ステージングエリアに存在する変更をローカルリポジトリに反映する
    #コミットメッセージは「変更の概要」か「なんのためにこの変更を行ったか」を書くとよいと言われている
#下の「他の人の作業を、自分の作業に反映する (更新を取り込む)」を行う 
git push origin ${BRANCH_NAME} #ローカルリポジトリの変更をリモートリポジトリに反映する（自分の作業をGitHubにセーブ）

他の人の作業を、自分の作業に反映する (更新を取り込む)/いわゆるpullする

push先のブランチが自分以外のコミットを受けているとmergeできないので、pushの時点でエラーを起こす。
                           他の人のmerge
                                         ↓
main                   A -- B -- C -- D -- F
                                  ↓             ×
       Localにcehckout ↓             ↑ 依存先が変更されるとpushできない
working-branch         D ------- E
このため、リモートのmainブランチが変更を受けたら、それを自分の作業ブランチにも反映させなければならない。
                             他の人のmerge
                                        ↓
main                  A -- B -- C -- D -- F----H
                                 ↓        ↓ fetch         ↑ push/merge
                        Local ↓           ⤵ merge ↑
working-branch        D -- E -- G→→→⤴

git fetch origin main
    #リモートのmainブランチの更新を仮置き場(origin/mainと名付けられている)に持ってくる
git merge origin/main ${WORKING_BRANCH}
    #origin/mainという仮置き場にある更新をマージする。こうするとログをきちんと表示してくれる（以前のやり方だとマージできないことしか表示してくれず、何が問題になっているかわからない
    #ログにCONFLICTが表示された場合
        git status
            #どのファイルがどうコンフリクトしているかとどうすれば解決できるかが表示されるので、あとは手動で解決する。 
        #解決したら、もう一度merge (mergeコマンドがコンフリクトにより中断されているため再実行が必要)
        git merge origin/main ${WORKING_BRANCH}

下だとうまくいかなかった。
git diff HEAD..origin/working-branch #コンフリクトを起こさないか確認
git pull origin ${working-branch} #カレントブランチに、カレントブランチの分岐元のブランチ（未設定の場合、ローカルブランチmaster）の最新情報をmergeする。
一気にやるとちゃんとコンフリクトの状態を吐いてくれない。diffの挙動もよくわかんないけど怪しい。何か間違えている気がする。

他のブランチの動作確認を行う（コードレビュー）/リモートブランチをローカルに複製する

git branch -r #pullしたいリモートブランチの名前を確認する
git checkout ${REMOTE_BRANCH} #自動で新規ブランチ（リモートブランチと同名）が切られる。同時にリモートブランチがローカルブランチにpullされる。

最初は以下を使っていた。
上のほうが本質的というか、動きが理解しやすくて好きだけど、調べたメモが残っているので置いておく。
cf. https://qiita.com/great084/items/ad74dd064a2c2bc47cff

プルリクエストの内容をローカル環境で稼働確認する(github) - Qiita

git fetch origin pull/${ID}/head:${NEW_BRANCH_NAME} #PRされているリモートブランチを、${NEW_BRANCH_NAME}というローカルブランチとしてローカルリポジトリにコピーする。
git swich ${NEW_BRANCH_NANE$}
 

<解説> fetch -> 本来はローカルリポジトリのorigin/mainという仮置きブランチに持ってくるだけ（見た目上ローカルリポジトリに反映しない）
pull/${ID}/head: -> GitHub上のPRを指定する書式。
headはリモートブランチにおけるheadの意味らしい？(chatGPT曰く)
この一行のコマンドはおおよそ
git checkout -b ${NEW_BRANCH_NAME}
git pull origin ${REMOTE_BRANCH_NAME}
をやっていると思われる。

その他便利コマンド

特定のコミットにブランチを戻す

git log #戻したいコミットのコミットハッシュを確認する(コミットの一番上の行の、英数字の羅列)
git reset ${COMMIT_HASH}

デバッグしてたらグチャグチャになってきたときに便利

四の五の言わずに特定のリモートブランチでローカルブランチを上書きする

 git branch #今いるブランチが上書きされてほしいブランチであることを確認
 git fetch origin git reset --hard ${対象のブランチ（のorigin/hogeバージョン）}

破壊したときに完全初期化するのに便利

おまけ

git checkout
git switch
git branch
全部ブランチ操作で同じじゃないですか！
checkoutが一番歴史が古く、多機能。ブランチ操作の他、ファイルの削除・復元などもつめこまれている。 多機能すぎて混乱するためこれらの機能はgit switchとgit restoreに分割されたらしい。
git branchは大幅に異なる。git branchは主にブランチ一覧表示や削除など、「ブランチに対して」何かするときに使う。
結論、switchとcheckoutはどっち使ってもいい。branchは全然違う。

いろいろ参考資料

https://git-scm.com/book/ja/v2/Git-のブランチ機能-ブランチとマージの基本#r_basic_merging

Git - ブランチとマージの基本

https://qiita.com/mareinu/items/c3f1b2b7419b7646ac47

【Git】【初心者】「git pull」ってのを魔法の言葉だと思っていたよ、私は。 - Qiita

https://qiita.com/wann/items/688bc17460a457104d7d