2026年10月8日にGitのpull、fetch、merge、rebase公式マニュアルを再確認した。fetchはremoteから参照とオブジェクトを取得し、pullはfetch後に統合し、mergeは履歴を結合し、rebaseはcommitの土台を付け替える。取得先、未コミット変更、統合方針、競合、共有済み履歴、レビュー・CIを別欄に置き、pullを「最新化して安全に公開する」単一操作とは扱わない。
プルは、別のリポジトリから履歴を取得し、現在のブランチへ取り込む操作です。「メールを受信する」という比喩は取得の部分には近いですが、pullはその後の統合まで行います。ファイルをダウンロードして眺めるだけの操作とは区別しましょう。
30秒で要点
- pullはfetchと統合を組み合わせた操作。取得だけ確認したい場面ではfetchで止められます。
- 取得元、現在branch、upstream、統合方針を確認します。引数なしpullが常にorigin mainを対象にするわけではありません。
--ff-onlyは分岐した履歴を拒否します。競合の予防や、送信していないデータの復元を保証する操作ではありません。
fetchで止まる場所とpullが進む場所
git-fetchは、必要な履歴objectと参照を取得します。通常のclone設定なら、取得内容に応じてorigin/mainなどのremote-tracking branchが更新されます。これはremoteそのものではなく、手元にある取得時点の参照です。 git-pullは、取得後に対象履歴を現在branchへ統合します。既定の挙動はGitの版や設定にも依存するため、本記事の練習では方針を明示します。
図ではremoteがAからBへ進んでいても、fetchだけなら手元mainのHEADはAに残ります。その後FF可能な統合を行うとmainもBを指します。取得1回と統合1回を分けて数える例で、通信時間や処理回数の性能予測ではありません。
3段階で安全に確認する
以下は、originを設定済みでmainを利用する練習用cloneの例です。remoteはインターネット上とは限らず、別フォルダーのリポジトリも使えます。本文の教材検証はローカルの練習先だけで行い、公開サービスへ送信する操作は含めません。
1. 取得元と現在地を見る
git status --short
git branch --show-current
git remote -v
git branch -vvremote -vの表示例origin https://github.com/username/repository.gitは、名前とURLの対応を説明するものです。実在の送信先として貼り付ける指示ではありません。originは慣用的な名前、mainはbranch名です。branch -vvで追跡先も確認します。URLには認証情報が含まれる場合があるので、そのまま外部へ共有しないでください。
2. 取得後の差を確認する
git fetch origin
git log --oneline --graph --all
git diff HEAD origin/main元の教材のgit fetchにも「取得するが現在branchへ統合しない」という役割があります。「変更はまだダウンロードしない」という説明は誤りです。fetch後に履歴や差分を見れば、ローカルの作業を統合する前に対象を把握できます。特殊なrefspecや設定では更新対象が異なるため、上の例は通常のclone設定を前提にしています。
3. 方針を指定して取り込む
git pull --ff-only origin main
git status --short
git log -1 --onelineこれはoriginのmainを現在のbranchへ統合する指定です。mainへ切り替える指定ではありません。自分のmainに独自commitがなく、取得先がその先へ進んだ場合はFFできます。独自の履歴と分岐した場合は拒否します。拒否後に強制するのでなく、両側の変更と運用方針を確認してください。
旧表記のgit pull origin mainは統合方式を明示していません。引数なしのgit pullも、現在branchのupstreamなどの設定を使います。「通常origin mainだから」と推測せず、対象を確認する習慣を付けます。
merge、rebase、ff-onlyを分けて選ぶ
表が収まらない場合は、横にスクロールできます
| 方針 | 意味 | 分岐した場合の判断 |
|---|---|---|
git pull --ff-only | 参照の前進で取り込める場合に限定する | 拒否後に履歴を確認する |
git pull --no-rebase | fetch後にmerge方式で統合する | 競合があれば内容を解決する |
git pull --rebase | fetch後にlocal commitを再適用する | 共有履歴の扱いを先に合意する |
FFは祖先関係に基づく参照移動です。「競合がなかったら全部FF」という意味ではありません。mergeもrebaseも、自動で内容が合わなければ停止します。処理中はstatusを確認し、mergeならmergeの続行・中止、rebaseならrebaseの続行・中止を使います。解決前に何度もpullを重ねる手順にはしません。mergeとrebaseは異なる処理です。
作業タイミングとエラーの見分け方
ブログの記事追加、CSSデザイン、認証機能、企業サイトのお知らせなど、他メンバーの変更を把握してから作業すると手戻りを減らせる場合があります。ただし、その後に別の更新が入る可能性は残り、pullが競合を防いでくれるわけではありません。
表が収まらない場合は、横にスクロールできます
| 状況 | 確認すること | 対処の方向 |
|---|---|---|
| 作業を始める前 | 作業先、remote、未commit変更 | 必要な履歴を確認して取り込む |
| 未保存の編集がある | エディタにだけ残る内容 | まず保存・保全する |
| 保存済みだが未commit | Git上の差分と統合への影響 | 必要な内容を保全し、無理に上書きしない |
| ff-onlyが拒否 | local/remoteの分岐 | 許可された統合方式を相談する |
| 競合処理中 | statusと未解決ファイル | 解決して続行するか、保全の上で中止する |
| 取り込み後に動作不良 | 差分、依存関係、検証結果 | 原因を特定し、合意した復旧を行う |
たとえばindex.htmlを触る前に最新履歴を確認する意味は、他者の変更を把握することです。1日1回という回数だけでは、共有状態も内容の正しさも保証できません。取り込み後は対象機能をテストします。
復元できるデータには範囲がある
端末を失ったとき、remoteへ送ってある履歴はgit cloneで取得し直せます。既存cloneを更新するpullと、新しいcloneを作る操作は役割が違います。clone後に追加更新をpullする場面はありますが、cloneとpullを行えばすべての作業が戻るという説明はできません。
まだpushしていないcommit、未追跡ファイル、Git外のデータや環境設定は別です。Git LFSやsubmoduleなどの追加の取得条件がある構成もあります。pushは履歴を別のリポジトリへ送る側の操作ですが、pullと機械的に逆順にすれば完全なバックアップになるという意味ではありません。