先に要点
- 関係はシンプルで、git pull = git fetch + 統合(merge または rebase)です。pull は「取ってくる」と「取り込む」を一気にやります。
- git fetchは、リモートの変更を 取得してリモート追跡ブランチ(
origin/mainなど)を更新するだけ。現在のブランチや作業ツリーは変えないので 安全に「差分の下見」ができます。 - git pullは、fetch したうえで 現在のブランチに merge(既定)または rebase で取り込むため、コンフリクトやマージコミットがその場で発生し得ます。
- 迷ったら fetch して
git log origin/mainで中身を確認 → 問題なければ merge / rebase、という2段階が安全。pull はそれを1コマンドにまとめた近道です。 - 統合方法は選べます。履歴を残すなら merge、直線的にしたいなら rebase(
git pull --rebase)。Git 2.27以降は方針未設定だと pull 時に警告が出るので、方針を決めておきます。
git pull と git fetch、どっちを使えばいいの？ ── Git を使い始めて必ず迷うところです。どちらも「リモートの最新を持ってくる」操作に見えますが、作業中のブランチを書き換えるかどうかが決定的に違います。ここを理解すると、「pull したら急にコンフリクトが出た」「知らないうちにマージコミットが増えた」といった事故を避けられます。
この記事では、両者の違いを pull = fetch + 統合という関係 → それぞれの挙動 → リモート追跡ブランチ → merge か rebase か → 安全な使い分けの順で整理します。挙動はGit公式ドキュメントの git-fetch / git-pull を確認しながらまとめています。
まず全体像: pull = fetch + 統合
いちばん大事な一文はこれです。git pull は、git fetch と、その後の統合(merge または rebase)を、まとめて実行するコマンドです。
つまり、fetch は pull の前半だけを実行するコマンドです。「pull は fetch より一歩踏み込んで、手元のブランチまで更新する」と捉えると、両者の関係がすっきりします。
git fetch は何をするか(安全な下見)
git fetch は、リモートリポジトリから最新のコミットやブランチ情報を ダウンロードするだけのコマンドです。重要なのは、現在チェックアウトしているブランチも、作業ツリー(編集中のファイル)も一切変更しない点です。
取得した内容は、リモート追跡ブランチと呼ばれる origin/main のような参照に反映されます。これは「リモートの main が今どこまで進んでいるか」を指すローカルのしおりのようなものです。だから fetch の後は、こう確認できます。
| やりたいこと | コマンド |
|---|---|
| リモートの最新を取得(まだ取り込まない) | git fetch origin |
| 取得した変更の中身を見る | git log main..origin/main |
| 差分をファイル単位で見る | git diff main origin/main |
| 確認して問題なければ取り込む | git merge origin/main（または rebase） |
このように、fetch は「取り込む前に中身を確認できる」安全な操作です。人のブランチを覗きたいとき、リベース前に最新を取り込みたいとき、コンフリクトが怖いときに、まず fetch しておくと落ち着いて判断できます。
git pull は何をするか(取得＋取り込み)
git pull は、fetch に続けて 現在のブランチへ取り込む(統合する)ところまで一気に行います。既定では mergeで統合します。手元にコミットが無くリモートだけが進んでいれば、単に最新へ追いつくだけ(fast-forward)で済みますが、手元とリモートの両方が進んでいると、マージコミットが作られたり、コンフリクトが発生したりします。
pull はリモートを取り込むところまでやるため、コンフリクトの解決やマージコミットの発生が、実行したその瞬間に起きます。中身を見てから取り込みたいなら fetch を先に使います。
git pull と git fetch の比較
| 観点 | git fetch | git pull |
|---|---|---|
| やること | リモートの変更を取得するだけ | 取得＋現在ブランチへ統合 |
| 現在のブランチ | 変更しない | 変更する(merge / rebase) |
| 作業ツリー | 変更しない | 変更される |
| コンフリクト | 起きない | 起き得る |
| 安全性 | 高い(下見向き) | 取り込むぶん影響が大きい |
| 中身の事前確認 | できる | 取り込んでから気づく |
リモート追跡ブランチ(origin/main)を理解する
fetch と pull の違いを腹落ちさせる鍵が リモート追跡ブランチです。main は自分の作業ブランチ、origin/main は「最後に通信したときのリモートの main の位置」を指すローカルのしおりです。
- git fetch ──
origin/main(しおり)だけを最新に動かす。自分のmainはそのまま。 - git merge origin/main ── 自分の
mainをorigin/mainに合流させる。 - git pull ── 上の2つを続けて実行する。
だから「fetch しても手元が変わらない」のは当然で、fetch はしおりを進めるだけ。実際に自分のブランチへ反映するのは merge / rebase(または pull)の役目、という分担です。
merge か rebase か(pullの統合方法)
pull の統合方法は選べます。ここはチームの方針に関わる大事なポイントです。
Git 2.27以降は、統合方針(merge か rebase か)を設定していないと、pull のたびに警告が出ます。曖昧なまま使わず、git config --global pull.rebase false(merge) か true(rebase)、あるいは git config --global pull.ff only(fast-forwardのみ許可)で方針を決めておくと、事故が減ります。マージとリベースの考え方そのものは奥が深いので、チームのルールに合わせるのが基本です。
安全な使い分け(実務の型)
日常的には git pull 一発でも回りますが、大きな変更が来ていそうなとき・長く放置したブランチ・リベース前は、fetch して中身を見てから取り込むと安全です。「普段は pull、心配なときは fetch して下見」と覚えておくと実務で困りません。
よくある誤解・失敗
fetch すれば手元も最新になる?
なりません。fetch は origin/main を更新するだけで、自分のブランチは merge / rebase するまで変わりません。
pull したら急にコンフリクト
pull は統合まで走るため。先に fetch して差分を確認していれば心の準備ができます。
意図しないマージコミットが増える
既定の merge 統合が原因。直線的にしたいなら git pull --rebase や pull.rebase を設定する。
pull.rebase 未設定の警告
Git 2.27以降の仕様。放置せず pull.rebase か pull.ff を明示して方針を固定する。
git pullとgit fetchに関するよくある質問
git pull と git fetch の一番の違いは何ですか？
現在のブランチを書き換えるかどうかです。git fetch はリモートの変更を取得してリモート追跡ブランチ(origin/main)を更新するだけで、作業中のブランチや作業ツリーは変えません。git pull はそれに加えて、現在のブランチへ merge または rebase で取り込みます。
結局どちらを使えばいいですか？
普段の「最新に追いつく」だけなら git pull で十分です。ただし、大きな変更が来ていそうなとき、長く放置したブランチ、リベース前は、先に git fetch して中身を確認してから取り込むと安全です。
git fetch した後、手元に反映するには？
git merge origin/main(または git rebase origin/main)を実行します。これで取得済みの変更が現在のブランチに取り込まれます。fetch＋merge を一度にやるのが git pull です。
git pull で毎回警告が出るのはなぜですか？
Git 2.27以降では、pull の統合方針(merge か rebase か)を設定していないと警告が出ます。git config --global pull.rebase false(merge固定)か true(rebase固定)、または pull.ff only を設定すれば消えます。
git pull --rebase は何が違いますか？
統合を merge ではなく rebase で行います。自分のコミットをリモートの最新の先端に載せ替えるため、履歴が直線的で読みやすくなります。ただしコミットのハッシュは作り直されるので、すでに共有(push)済みのコミットに対しては使わないのが安全です。
fetch と pull はどのくらいの頻度でやるべきですか？
チーム開発では、作業を始める前と、こまめに取得するのが基本です。放置するとリモートとの差が開き、後で大きなコンフリクトになりがちです。まず fetch で差分を見る習慣をつけると、取り込みの判断がしやすくなります。
まとめ
git pull と git fetch の違いは、git pull = git fetch + 統合(merge / rebase)という関係に集約されます。fetch はリモート追跡ブランチを更新するだけで手元を変えない安全な下見、pull はそこから現在のブランチへ取り込むまで一気にやる操作です。日常は pull で回し、心配なときは fetch して中身を見てから統合する。統合方法(merge / rebase)の方針を決めておけば、意図しないマージコミットやコンフリクトの事故も減らせます。関連して、リポジトリの複製の話はGitのforkとcloneの違い、pull でコンフリクトが出たときの対処はGitでpull時に未コミットの変更で怒られたときの対処も参考になります。
参考リンク
- Git 公式: git-fetch ドキュメント
- Git 公式: git-pull ドキュメント
- 用語集: Git / プルリクエスト