Gitのfetchとpullの違いは何か。更新を安全に取り込む基本手順

Gitでリモートの更新を取り込むとき、まず押さえたい結論はシンプルです。git fetchは更新を取り込んで確認する操作、git pullは更新を取り込んで今のブランチへ反映する操作です。

作業中の変更を壊したくない、競合を先に見たい、レビュー前に差分を確認したい。そういう場面では、いきなりpullするよりfetchから入るほうが安全です。逆に、手元にローカル変更がなく、追従だけしたい場面ではpullのほうが早く済みます。

• git fetch: リモートの最新状態を取得するが、作業中のブランチはそのまま
• git pull: fetchしたあと、その内容を現在のブランチへ統合する
• 安全重視なら、まずfetchしてからgit logやgit diffで確認する
• 自動反映が必要でも、git pull --ff-onlyやgit pull --rebaseの使い分けを覚えると事故が減る

ここがポイント: 迷ったら先にfetchです。更新内容を見てから反映するだけで、意図しないマージや競合の混乱をかなり減らせます。

まず違いを整理する

この2つは似ていますが、止まる場所が違います。

git fetchは「取り寄せて止まる」

git fetch originを実行すると、Gitはリモートリポジトリの更新を取得し、origin/mainのようなリモート追跡ブランチを更新します。

ただし、いま自分が作業しているmainやfeature/loginは書き換えません。つまり、更新を受け取っても、作業ツリーはそのままです。

この挙動が重要なのは、次のような場面です。

• ほかの人のコミットを確認してから取り込みたい
• 自分のブランチがどれだけ遅れているか見たい
• force pushが入っていないか確かめたい
• マージ前に差分をレビューしたい

git pullは「取り寄せて反映する」

git pullは、公式ドキュメントでもまずfetchを実行し、その後に現在のブランチへ統合するコマンドとして説明されています。

統合の方法は1つではありません。現在のGitマニュアルでは、主に次の選択肢があります。

• git pull --ff-only: fast-forwardできるときだけ更新する
• git pull --rebase: 自分のローカルコミットを後ろに積み直す
• git pull --no-rebase: マージで取り込む
• git pull --squash: squash mergeとしてまとめる

実務では、「ただ最新に追従したい」なら--ff-only、履歴を直線的に保ちたいなら--rebaseという考え方が分かりやすいです。

対象環境と前提

この記事の説明は、2026年4月24日時点で確認できるGit公式ドキュメントを前提にしています。git-fetchとgit-pullのマニュアルは、どちらもGit 2.53.0系の内容を参照しています。

想定環境は次のとおりです。

• Git Bash
• macOSのTerminal
• Linuxシェル
• GitHubやGitLabなど、一般的なリモートリポジトリ運用

まずは自分の環境を確認しておくと混乱しにくくなります。

git --version
git remote -v
git branch -vv

見るポイントは3つです。

• Gitのバージョン
• どのリモートを見ているか
• 今のブランチがどの上流ブランチを追跡しているか

基本の書き方と最小コマンド例

ここでは、origin/mainを追跡しているローカルmainを例にします。

1. 更新内容だけ取得したいとき

git fetch origin

この時点で起きることは次のとおりです。

• リモートの最新コミット情報を取得する
• origin/mainの位置が更新される
• ローカルのmainはまだ変わらない

続けて差分を見ると、取り込む前の確認ができます。

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

入力例のイメージ:

• ローカルmainはコミットA
• リモートorigin/mainはA-B-Cまで進んでいる

出力例のイメージ:

9f3a210 Fix CSV export header
27ac8d1 Add retry handling for API timeout

この2行が見えたら、まだ手元のmainは変わっていないが、リモートには2コミット分の更新があると分かります。

2. そのまま最新へ追従したいとき

git pull --ff-only origin main

この書き方は、ローカルに独自コミットがなく、fast-forwardだけで進めるときに向いています。

• 余計なマージコミットを作りにくい
• 分岐していたら失敗して止まる
• 失敗したときに状況を見直しやすい

出力例のイメージ:

Updating 1a2b3c4..5d6e7f8
Fast-forward
 README.md | 4 ++--
 app.js    | 8 +++++---

3. 自分のコミットを残して更新したいとき

git pull --rebase origin main

これは、リモート更新を先に取り込んだうえで、ローカルのコミットをその後ろへ並べ直す方法です。履歴が見やすくなりやすい反面、すでに共有したコミットをrebaseすると履歴を書き換えるので、チーム運用のルール確認が必要です。

4. fetchしてから自分で反映する方法

自動反映を避けたいなら、2段階に分けると状況を制御しやすくなります。

git fetch origin
git merge origin/main

または、rebaseで反映したいならこちらです。

git fetch origin
git rebase origin/main

この分け方の利点は、途中で差分確認やバックアップ判断を挟めることです。

実務での使いどころ

操作の違いは分かっても、どちらを選ぶかで迷いやすい場面があります。そこで、よくあるケース別に整理します。

朝いちでリモートの状況だけ確認したい

おすすめはfetchです。

git fetch origin
git status
git log --oneline --decorate --graph HEAD..origin/main

これなら、今のブランチを動かさずに、どんな更新が来ているかだけ見られます。レビュー前や、複数人が同じブランチを触る案件で特に有効です。

自分は変更しておらず、最新へ合わせたい

おすすめはpull --ff-onlyです。

git pull --ff-only

ローカルで余計なコミットを作っていない前提なら、短く安全に追従できます。

自分もコミットしていて、履歴を整理したい

おすすめはpull --rebase、またはfetch後にrebaseです。

git fetch origin
git rebase origin/main

履歴が一直線になりやすいので、PRや差分レビューが読みやすくなります。ただし、公開済みコミットに対して無造作に使うのは避けるべきです。

チームでマージ方針が決まっている

その場合は、個人判断よりリポジトリの運用ルールを優先します。

確認したい項目は次のとおりです。

• pull.rebaseが設定されていないか
• pull.ffの方針が決まっていないか
• mainブランチへの直接コミットを避ける運用か
• PRマージ後にローカルをどう同期するか

よくある失敗と対処

ここが実務では一番重要です。pullは便利ですが、分かっていないまま使うと履歴が読みにくくなります。

失敗1: 何が入ったか分からないままpullする

症状:

• いつの間にか大量の変更が入る
• 競合が起きた理由が追えない
• マージコミットが急に増える

対処:

• まずgit fetchする
• git log HEAD..origin/mainで取り込み対象を見る
• 差分が大きいときは、すぐ反映せず確認する

失敗2: ローカル変更がある状態でpullして競合する

未コミット変更があるままpullすると、統合時に衝突しやすくなります。

対処の流れ:

• git statusで変更有無を確認する
• 必要なら先にgit addとgit commitをする
• 一時退避ならgit stashを使う

git status
git stash
git pull --rebase
git stash pop

失敗3: pull --rebaseで履歴を書き換えて混乱する

rebaseは便利ですが、共有済みコミットに使うと、他メンバーの履歴とずれることがあります。

避けたい場面:

• すでにpush済みのブランチを複数人で共有している
• 運用ルールがmerge前提になっている
• rebase後のforce pushに慣れていない

迷うなら、fetchして差分確認後に通常のmergeを選ぶほうが安全です。

失敗4: 削除済みリモートブランチが残り続ける

fetchだけでは、古い追跡ブランチが残ることがあります。ブランチ整理をしたいなら、--pruneを覚えておくと便利です。

git fetch --prune origin

これで、リモート側ですでに削除されたブランチに対応するローカルのリモート追跡参照を整理できます。

NG例と改善例

NG例: とりあえず毎回git pull

git pull

この1行は短いですが、今のブランチ状況や設定次第で結果が変わります。mergeになるのか、rebaseになるのか、fast-forwardだけなのかを把握していないと、あとで履歴を読む人が困ります。

改善例: まず確認してから取り込む

git fetch origin
git log --oneline HEAD..origin/main
git pull --ff-only origin main

この流れなら、更新内容を見てから安全に反映できます。特に初心者のうちは、確認を1ステップ挟むだけで事故率が大きく下がります。

fetchとpullの使い分け早見表

場面	向いている操作	理由
更新内容を先に確認したい	git fetch	作業中ブランチを変えずに情報だけ取得できる
ローカル変更がなく、そのまま最新にしたい	git pull --ff-only	余計なマージを避けて追従しやすい
自分のコミットを整理して最新へ乗せたい	git pull --rebase	履歴を直線的に保ちやすい
反映方法を自分で選びたい	git fetch後にmergeまたはrebase	途中確認を挟めて制御しやすい
古いリモート追跡ブランチも整理したい	git fetch --prune	削除済みブランチの参照を掃除できる

関連コマンドと代替手段

fetchとpullだけ覚えるより、周辺の確認コマンドもセットで使うと実務で強くなります。

差分確認に使うコマンド

git status
git log --oneline --graph --decorate --all
git diff HEAD..origin/main

これらは、反映前の判断材料になります。特にgit statusは、未コミット変更の有無を確認する基本です。

upstream設定を確認するコマンド

git branch -vv
git config --get-regexp '^branch\.'

pullは、どの上流ブランチを見ているかで動作対象が変わります。意図しないブランチを取り込まないためにも、一度は確認しておきたいところです。

設定を明示したいとき

git config pull.rebase true
git config pull.ff only

ただし、この設定はチーム運用に直結します。個人環境で便利でも、チーム標準とずれるなら、まず運用ルールを確認してください。

迷ったときの実務向け手順

最後に、判断に迷いにくい最小手順をまとめます。

1. git statusで未コミット変更がないか確認する
2. git fetch originで更新だけ取得する
3. git log HEAD..origin/mainやgit diffで内容を見る
4. 問題なければgit pull --ff-only、必要ならrebaseやmergeを選ぶ

この流れを習慣にすると、pullをただの「同期ボタン」として使わずに済みます。

今後の注目点もここです。

• 自分のチームはmerge中心かrebase中心か
• pull.ffやpull.rebaseがどう設定されているか
• mainで直接更新するのか、PR経由で同期するのか

fetchとpullの違いを理解する価値は、コマンドを暗記することではありません。更新を取り込む前に一度立ち止まれることにあります。そこを押さえるだけで、Gitの事故はかなり減ります。

参照リンク

• Git公式: git-fetch Documentation
• Git公式: git-pull Documentation
• Git公式: pull-fetch-param Documentation
• Git公式: git-config Documentation