git pullって、実は2つのコマンドの合わせ技だった

おはようございます、YASUです。

今日は普段あまり主役になることのない git fetch について。git pull は毎日のように使っていましたが、fetchはずっと素通りしていたコマンドでした。改めて役割を整理してみたら、実はpullの裏側で起きていることが見えてきたので、構造化してまとめておきます。

結論

git fetchは「リモートの最新情報を取ってくるだけ」のコマンドで、自分の作業中のファイルには一切影響しません。一方git pullは、その取得したあとに「自分のブランチへ合体(マージ)する」までを一気にやってくれるコマンドです。実はpullは、fetchとmergeをセットにした合わせ技でした。

まず、2つのコマンドの中身を分解する

git pull  =  git fetch  +  git merge

普段何気なく打っているgit pullは、実はこの2段階の処理を1回のコマンドでまとめてやってくれています。

pullはこの2つを一気に実行するので、普段は気にせず使えて便利な反面、「今、実際に自分のファイルに変更が加わったのか」が一瞬で分かりにくい、という側面もあります。

それぞれのコマンドを実行すると、何が起きるか

【git fetch実行後】
リモートの最新情報 ──→ 自分のPC内に保管(.gitフォルダの中)
自分の作業中のファイル ──→ 変化なし

【git pull実行後】
リモートの最新情報 ──→ 自分のPC内に保管
                    ──→ さらに自分のブランチに合体
自分の作業中のファイル ──→ 変化する(最新の内容が反映される)

つまりfetchは「まだ見ていない郵便物を、とりあえず郵便受けから取ってきた」状態、pullは「取ってきた郵便物を、封を開けて中身を自分の部屋に取り込んだ」状態、というイメージです。

なぜわざわざfetchだけを使う場面があるのか

いきなりpullしてしまうと、リモートの変更内容が問答無用で自分のブランチに合体されます。もし自分が今まさに何かを編集中で、リモートの変更とぶつかりそうな内容だった場合、突然コンフリクト(競合)が発生して作業が止まってしまうことがあります。

fetchを使えば、まず「リモートに何か新しい変更が来ているか」だけを安全に確認できます。

git fetch
git log HEAD..origin/main --oneline

このように、fetchした後に差分だけを確認するコマンドを組み合わせれば、「どんな変更が来ているか」を、自分のファイルに一切触れずに事前チェックできます。中身を見て問題なさそうであれば、そこから改めてgit merge(またはgit pull)を実行する、という2段階の慎重な進め方ができるわけです。

構造で整理すると

                 ┌─ 確認だけしたい ──→ git fetch(安全、ファイルは変化しない)
リモートの変更 ──┤
                 └─ すぐ取り込みたい ──→ git pull(fetch + merge を一括実行)

実務でどちらを使うべきか

個人開発やシンプルなワークフローでは、正直git pullだけで十分なことがほとんどです。ただ、チーム開発で複数人が同時に同じブランチを触っているような場面では、

という慎重な運用をしているチームもあります。以前触れた「心配性な性格は、こまめな確認習慣と相性が良い」という話にも通じますが、いきなりpullで全部取り込むより、fetchで一呼吸置いて確認する、という進め方は事故予防の観点でも理にかなっています。

まとめ

普段何気なく打っているコマンドも、裏側の構造を分解してみると、また少し解像度が上がった気がします。それでは、また明日!