【図解】git fetchとpullの違いとは？チーム開発で必須のリモート操作を徹底解説！
git pullをいきなり実行して、先輩のコードと衝突…。そんな冷や汗をかいた経験はありませんか？
一人での開発は順調だったのに、チーム開発になった途端、Gitの使い方が分からなくなる。多くのジュニアエンジニアが同じ壁にぶつかります。特にpullとfetchの違いは、最初の大きなつまずきポイントです。
ご安心ください！この記事を読めば、もうリモート操作は怖くありません。チーム開発の基本となるgit fetch, git pull, git pushについて、なぜfetchから始めるのが安全なのか、その理由を図解とストーリーでどこよりも分かりやすく解説します。
この記事を読み終える頃には、あなたは…
fetchとpullの明確な違いを、自信を持って説明できるようになる。- チーム開発での安全なGit操作サイクルを体得できる。
- コンフリクトを未然に防ぎ、落ち着いて対処できるようになる。
- 他のメンバーに迷惑をかけない、信頼されるチームの一員としての一歩を踏み出せる。
対象読者
この記事は、特に以下のような方を対象としています。
- Gitを学び始めたばかりで、
pullとfetchの違いがよく分からない方 - 一人での開発経験はあるが、チーム開発は初めてで不安な方
- チーム開発で他のメンバーに迷惑をかけないか、操作のたびに心配になる方
目次
なぜチーム開発は難しい？2つの世界を理解しよう
まず、チーム開発で混乱しないために、Gitが管理する2つの世界を意識しましょう。
- ローカルリポジトリ: あなたのPCの中にある、自分だけの作業スペース。
- リモートリポジトリ: GitHubなどにある、チーム全員で共有する保管場所。
一人での開発は、ローカルリポジトリという閉じた世界だけで完結します。しかしチーム開発では、リモートリポジトリを介して、他のメンバーとコードをやり取りする必要が出てきます。この「やり取り」に使うのが、fetch, pull, pushなのです。
シナリオで学ぶ！チーム開発のとある一日
具体的なイメージを掴むために、AさんとBさん、2人のエンジニアが登場するストーリーで見ていきましょう。
登場人物:
- Aさん: 先輩エンジニア。新しい機能を追加中。
- Bさん: あなた（ジュニアエンジニア）。Aさんの作った機能を使って、別の作業を始めたい。
Step 1: Aさんが変更を共有する (git push)
Aさんは、担当していた新機能「ログインボタンの追加」を完成させ、自分のPC（ローカル）からチームの共有場所（リモート）へその変更を送信しました。
# AさんのPCでの操作
git commit -m "feat: ログインボタンを追加"
git push origin mainこのgit pushにより、リモートリポジトリのmainブランチが更新され、Aさんの書いたコードがチームに共有されました。
Step 2: Bさんが変更を確認する (git fetch)
さて、あなたの出番です。Aさんが共有してくれた最新のコードを、自分のPCに取り込みたいと思います。しかし、いきなり自分の作業ファイルと混ぜてしまうのは少し怖いですよね。
そこで使うのが git fetch です。
git fetchは、リモートリポジトリの最新情報をあなたのPCにダウンロードするだけの安全なコマンドです。あなたの作業中のファイルには一切影響を与えません。
# BさんのPCでの操作
git fetch origin【何が起きた？】3つ目の場所「リモート追跡ブランチ」の登場
fetchを実行すると、あなたのローカルリポジトリの中に、リモートの状態を写す鏡のような特別な場所が作られます。これを「リモート追跡ブランチ」と呼びます。（origin/mainのような名前です）
fetchは、この「鏡」だけを最新の状態に更新します。あなたの作業場（ワーキングディレクトリやローカルのmainブランチ）は、まだ何も変わっていません。
【メリット】安全に差分を確認できる
「鏡」を更新したことで、自分の作業とリモートの最新版との間にどのような差分があるのかを、合体させる前に確認できます。
# BさんのPCでの操作
# リモートのmainブランチにどんなコミットがあるか確認
git log origin/main
# 自分のmainブランチとリモートのmainブランチの差分を確認
git diff main origin/mainこれにより、「Aさんはログインボタンを追加したんだな。自分の作業と被らなそうだから、取り込んでも大丈夫そうだ」と、自信を持って判断できます。
Step 3: Bさんが変更を取り込む (git merge or git pull)
リモートの変更内容を確認して、問題ないことが分かりました。いよいよ、その変更を自分の作業ブランチに取り込みます。方法は2つあります。
方法1: fetch と merge を分ける（推奨）
fetchで安全確認した後、git mergeコマンドでリモート追跡ブランチ（鏡）の内容を、自分のローカルブランチに合体させます。
# BさんのPCでの操作
# 1. まずはfetchで安全確認（Step 2で実施済み）
git fetch origin
# 2. mainブランチに移動
git checkout main
# 3. リモートの変更内容(origin/main)を現在のブランチ(main)に合体！
git merge origin/mainこの2段階のプロセスが、チーム開発における最も安全で確実な方法です。
方法2: git pull で一気に行う（慣れてから）
git pullは、これまで説明したgit fetchとgit mergeの2つのコマンドを、一度に実行してくれる便利なショートカットです。
# BさんのPCでの操作
git pull origin main【注意！】pullはコンフリクトのビックリ箱？
pullは便利ですが、「何が起きるか分からないまま、いきなり合体が始まってしまう」という側面も持っています。もし、あなたとAさんが同じファイルの同じ行を編集していた場合、pullを実行した瞬間にコンフリクト（コードの衝突）が発生し、あなたのターミナルはエラーメッセージでいっぱいになります。
初心者のうちは、まずfetchで心の準備をしてからmergeする癖をつけることを強くお勧めします。
コンフリクト発生！その時エディタでは何が起きている？
もしコンフリクトが発生すると、Gitはファイルの合体を中断し、該当のファイルを特殊な状態にします。エディタで開くと、以下のような記号が追加されています。
<<<<<<< HEAD
<p>これはあなたの変更です。</p>
=======
<p>これはリモートから来たAさんの変更です。</p>
>>>>>>> origin/main
<<<<<<< HEADから=======までが、あなたのPCで行った変更（HEAD）です。=======から>>>>>>> origin/mainまでが、リモートから取り込もうとした変更（origin/main）です。
Gitは「どちらの変更が正しいか、人間であるあなた自身で判断してください」と伝えてきています。
解決策:
- これらの記号（
<<<<<<<など）をすべて手動で削除します。 - どちらの変更を残すか、あるいは両方を活かす形にコードを編集します。
- ファイルを保存し、いつも通り
git addとgit commitを実行すれば、コンフリクト解決は完了です。
Step 4: Bさんも自分の変更を共有する (git push)
Aさんの変更を取り込み、Bさん（あなた）も自分の作業を進めてコミットしました。今度はあなたが、その成果をチームに共有する番です。使うコマンドはAさんと同じ、git pushです。
# BさんのPCでの操作
git commit -m "fix: ヘッダーの文言を修正"
git push origin main【もしpushが拒否されたら？】
pushを実行した際に、以下のようなエラーが出ることがあります。
! [rejected] main -> main (fetch first)<br>error: failed to push some refs to '...'これは「あなたがpushしようとしている間に、誰か他の人が先にpushしましたよ！」というGitからの親切なメッセージです。あなたの知らない変更でリモートの履歴を上書きしてしまわないように、Gitが安全に止めてくれています。
慌てる必要はありません。これはチーム開発では日常茶飯事です。解決策は、原点に戻ってリモートの最新情報を取り込むことです。
以下に、解決までの具体的なコマンドの流れを示します。
# 注釈： `$`はコマンドの入力を示す記号です。実際に入力する必要はありません。
# 1. 自分の変更をpushしようとするが...
$ git push origin main
# 以下はGitからの出力例。リポジトリ名やコミット内容は異なります。
To https://github.com/user/repo.git
! [rejected] main -> main (non-fast-forward)
error: failed to push some refs to 'https://github.com/user/repo.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
# 2. エラーメッセージに従い、まずリモートの最新情報をfetchする
$ git fetch origin
# 3. リモートの変更(origin/main)を、現在のブランチ(main)にmergeする
$ git merge origin/main
Merge made by the 'recursive' strategy.
some-file.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
# 4. ローカルで統合が完了したので、改めてpushする。今度は成功するはず！
$ git push origin main
To https://github.com/user/repo.git
abcdef0..7891011 main -> mainこのfetch -> merge -> push の流れを覚えておけば、pushが拒否されても落ち着いて対応できます。
まとめ：明日から実践する、安全なチーム開発サイクル
チーム開発は、個人の作業の連続ではありません。常にチームの動きを意識することが重要です。この記事で学んだ安全なサイクルを、明日からのあなたの習慣にしましょう。
- 作業を始める前は、まず
git fetch！- いきなり
pullせず、まずはfetchでリモートの様子を確認する癖をつけましょう。
- いきなり
pushが拒否されたら、慌てずfetch&merge！- エラーはGitからの親切なサインです。落ち着いて、もう一度リモートの変更を取り込みましょう。
- コンフリクトは、成長のチャンス！
- コンフリクトの解決は、最初は難しく感じるかもしれません。しかし、どの変更を優先すべきか考えることは、チームメンバーの意図を理解する良い訓練になります。
このサイクルを徹底すれば、予期せぬトラブルに怯えることなく、自信を持ってチーム開発を進めることができます。
コマンドリファレンス
この記事で登場した主要なコマンドの役割を再確認しましょう。
| コマンド | 一言でいうと | 動き | 安全性 |
|---|---|---|---|
git fetch | 確認する | リモートの最新情報をローカルのリモート追跡ブランチに持ってくるだけ。作業中のファイルには影響なし。 | ◎ 安全 |
git pull | 取り込む | fetchとmergeを同時に行う。リモートの最新情報を作業中のブランチにいきなり合体させる。 | △ 注意 （コンフリクトの可能性あり） |
git push | 共有する | ローカルでコミットした変更を、リモートにアップロードしてチームに共有する。 | △ 注意 （他人の変更を上書きしないよう、先に fetchが必要） |
【応用】知っておくと便利なコマンド
git remote add <name> <URL>：リモートリポジトリを登録する
git initで手元で作成したプロジェクトを、後からGitHub上に作成した空のリポジトリに接続したい場合に使います。git cloneで始めた場合は自動でoriginという名前で登録されるため、この操作は不要です。
# 'origin' という名前でリモートURLを登録
git remote add origin https://github.com/user/repo.gitgit push --force-with-lease：安全な強制上書き
【警告】 このコマンドは、rebaseなどでローカルのコミット履歴を書き換えた場合にのみ使用を検討する上級者向けのコマンドです。チームで共有しているmainブランチなどには絶対に使用しないでください。
--forceよりも安全で、自分が知らない変更がリモートに存在しない場合にのみpushを許可します。初心者のうちは、このようなコマンドが存在する、ということだけ知っておけば十分です。
git clone --depth 1: プロジェクトの最新版だけを素早く取得する
リポジトリの全履歴を含めず、最新の1コミット分だけの状態でリポジトリをクローンします。CI/CDパイプラインの処理時間短縮などに使われます。
参考資料
- Pro Git Book – リモートでの作業: https://git-scm.com/book/ja/v2/Git-の基本-リモートでの作業
- Git公式ドキュメント: git-remote
本記事をご利用いただくにあたって
この記事は、公開時点（2025年9月）の情報に基づき、正確な情報を提供するよう努めています。
しかし、本記事で解説するソフトウェアやサービスの仕様は日々更新されるため、記事内で紹介している画面や手順が、ご覧いただいている時点では変更されている可能性があります。
もし内容に相違がある場合は、各サービスの最新の公式ドキュメントも併せてご参照ください。本記事の情報を利用される際は、ご自身の判断と責任においてお願いいたします。
