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

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

以前少しだけ触れたgit fetchとgit pullの違いを、今日はもう少し深掘りしてみます。普段はpullだけで済ませていましたが、実務ではなぜfetchを使い分ける場面があるのか、改めて整理しました。

結論

git pullは、実はgit fetchとgit mergeを1つにまとめたコマンドでした。fetchは「リモートの最新情報を取ってくるだけ」で自分のファイルには影響しない一方、pullは取得した内容をそのまま自分のブランチに合体させます。この違いを理解すると、いきなり変更を取り込みたくない場面で、まず内容を確認してから判断する、という慎重な進め方ができるようになります。

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 pullだけで十分なことがほとんどです。ただ、チーム開発で複数人が同時に同じブランチを触っているような場面では、まずfetchでリモートの変更内容を確認してから、問題なさそうならmerge(またはpull)する、という慎重な運用をしているチームもあります。以前紹介した「心配性な性格は、こまめな確認習慣と相性が良い」という話にも通じますが、いきなりpullで全部取り込むより、fetchで一呼吸置いて確認する、という進め方は事故予防の観点でも理にかなっています。

まとめ

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