先に要点
- 関係はシンプルで、git pull = git fetch + 統合(merge または rebase)です。pull は「取ってくる」と「取り込む」を一気にやります。
- git fetchは、リモートの変更を 取得してリモート追跡ブランチ(
origin/mainなど)を更新するだけ。現在のブランチや作業ツリーは変えないので 安全に「差分の下見」ができます。 - git pullは、fetch したうえで 現在のブランチに取り込む(fast-forward・merge・rebase)ため、コンフリクトやマージコミットがその場で発生し得ます。
- 迷ったら fetch して
git log origin/mainで中身を確認 → 問題なければ merge / rebase、という2段階が安全。pull はそれを1コマンドにまとめた近道です。 - 統合方法は選べます。履歴を残すなら merge、直線的にしたいなら rebase(
git pull --rebase)。現在の Git は、方針を設定しないまま手元とリモートが分岐していると、pull が取り込まずにエラーで止まるので、方針を決めておきます。
git pull と git fetch、どっちを使えばいいの？ ── Git を使い始めて必ず迷うところです。どちらも「リモートの最新を持ってくる」操作に見えますが、作業中のブランチを書き換えるかどうかが決定的に違います。ここを理解すると、「pull したら急にコンフリクトが出た」「知らないうちにマージコミットが増えた」といった事故を避けられます。
この記事では、両者の違いを pull = fetch + 統合という関係 → それぞれの挙動 → リモート追跡ブランチ → merge か rebase か → 安全な使い分けの順で整理します。挙動はGit公式ドキュメントの git-fetch / git-pull を確認しながらまとめています。
まず全体像: pull = fetch + 統合
いちばん大事な一文はこれです。git pull は、git fetch と、その後の統合(merge または rebase)を、まとめて実行するコマンドです。
- 1
git fetch
リモートから最新のコミットを取得し、リモート追跡ブランチ(origin/main)を更新する。ここまでは現在のブランチに影響なし。
- 2
git pull
上の fetch を実行した後、続けて現在のブランチへ取り込む(fast-forward・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 に続けて 現在のブランチへ取り込む(統合する)ところまで一気に行います。手元にコミットが無くリモートだけが進んでいれば、単に最新へ追いつくだけ(fast-forward)で済みます。手元とリモートの両方が進んでいる(分岐している)と、merge ならマージコミットが作られ、rebase なら自分のコミットが載せ替えられ、どちらでもコンフリクトが起き得ます。なお、以前の Git は既定で merge していましたが、現在の Git は統合方法を設定していないと、分岐しているときは取り込まずにエラーで止まります(公式ドキュメントでは 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 の統合方法は選べます。ここはチームの方針に関わる大事なポイントです。
pullの統合: merge と rebase
merge
リモートの変更を取り込むマージコミットを作る。
- git pull --no-rebase で実行(pull.rebase false で既定化)
- 分岐と合流の履歴がそのまま残る
- 履歴は正確だが、マージコミットが増えて枝分かれしやすい
- 共有ブランチの取り込みで無難
こんな人向け履歴の正確さを優先・共有ブランチ
rebase
自分のコミットを最新の先端に載せ替える。
- git pull --rebase で実行(pull.rebase true で既定化)
- 履歴が直線的で読みやすくなる
- 自分のコミットのハッシュは作り直される
- 公開済みコミットのrebaseは避ける
こんな人向けフィーチャーブランチを綺麗に保ちたい
現在の Git では、統合方針(merge か rebase か)を設定していないと、手元とリモートが分岐しているときに pull が「Need to specify how to reconcile divergent branches」というエラーで止まります。曖昧なまま使わず、git config --global pull.rebase false(merge) か true(rebase)、あるいは git config --global pull.ff only(fast-forwardのみ許可)で方針を決めておくと、事故が減ります。マージとリベースの考え方そのものは奥が深いので、チームのルールに合わせるのが基本です。
安全な使い分け(実務の型)
pull で事故にならない基本の型
- 1作業前にまず fetch
git fetch origin で最新を取得。この時点では手元は変わらないので安全。
- 2中身を確認する
git log main..origin/main や git diff で、リモートに何が入ったかを見る。想定外の変更が無いか確認。
- 3問題なければ取り込む
git merge origin/main か git rebase origin/main で統合。あるいは最初から git pull(--rebase) にまとめてもよい。
- 4コンフリクトが出たら落ち着いて解決
該当ファイルを直して add → 続行。慌てて操作を重ねない。
日常的には git pull 一発でも回りますが、大きな変更が来ていそうなとき・長く放置したブランチ・リベース前は、fetch して中身を見てから取り込むと安全です。「普段は pull、心配なときは fetch して下見」と覚えておくと実務で困りません。
よくある誤解・失敗
fetch すれば手元も最新になる?
なりません。fetch は origin/main を更新するだけで、自分のブランチは merge / rebase するまで変わりません。
pull したら急にコンフリクト
pull は統合まで走るため。先に fetch して差分を確認していれば心の準備ができます。
意図しないマージコミットが増える
merge で統合している(pull.rebase false など)のが原因。直線的にしたいなら git pull --rebase や pull.rebase を設定する。
分岐していて pull が止まる
統合方針が未設定だと、分岐しているとき Git は取り込みを止めます。 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 で「divergent branches」と出て止まるのはなぜですか？
手元とリモートの両方に新しいコミットがあり(分岐していて)、pull の統合方針(merge か rebase か)を設定していないためです。Git 2.27 で警告が入り、その後の版では統合方法の指定が無いと fast-forward だけを行うようになりました。git config --global pull.rebase false(merge固定)か true(rebase固定)、または pull.ff only(分岐時は止まるのを明示)を設定するか、その回だけ --rebase / --no-rebase を付けて実行します。
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: Git 2.35.0 リリースノート（pull の案内文から「merge が既定」の記述を外した変更）
- 用語集: Git / プルリクエスト