
本記事の目的
「一人での開発は順調だったのに、チーム開発になった途端、Gitの使い方が分からなくなった…」
「pull
とfetch
って、何が違うの?」
「他の人のコードを消してしまったらどうしよう…」
Gitを学び始めたばかりのあなたが、チーム開発で最初にぶつかる壁が、リモートリポジトリとの連携ではないでしょうか。
この記事では、チーム開発の基本となるgit fetch
, git pull
, git push
について、それぞれの違いと正しい使い分けを、図解と丁寧な解説でどこよりも分かりやすく説明します。
この記事を読めば、こんなことが分かります
git fetch
,pull
,push
の明確な違い- チーム開発での安全なGit操作サイクル
- コンフリクトを未然に防ぐための考え方
- 他のメンバーに迷惑をかけない、自信を持ったGit操作
自分のPC(ローカルリポジトリ)から、みんなの共有スペース(リモートリポジトリ)へ!
安全にコードをやり取りする技術を身につけ、チーム開発への不安を自信に変えましょう!
目次
対象読者
この記事は、特に以下のような方を対象としています。
- Gitを学び始めたばかりで、
pull
とfetch
の違いがよく分からない方 - 一人での開発経験はあるが、チーム開発は初めてで不安な方
- チーム開発で他のメンバーに迷惑をかけないか、操作のたびに心配になる方
fetch, pull, push 早わかり比較表
まずは、3つのコマンドの役割をざっくりと掴みましょう。
コマンド | 一言でいうと | 動き | 安全性 |
---|---|---|---|
git fetch | 確認する | リモートの最新情報をローカルに持ってくるだけ。作業中のファイルには影響なし。 | ◎ 安全 |
git pull | 取り込む | リモートの最新情報をローカルに持ってきて、さらに作業中のブランチに自動で合体(マージ)させる。 | △ 注意 (コンフリクトの可能性あり) |
git push | 共有する | ローカルでコミットした変更を、リモートにアップロードしてチームに共有する。 | △ 注意 (強制上書きは危険) |
【重要】リポジトリの構成とコマンドの流れ
fetch
, pull
, push
を理解するには、まず最初に5つの場所(リポジトリ)の関係をイメージすることが必要です。この図を頭に思い浮かべながら読み進めると、各コマンドの動きが具体的に分かるようになります。
リポジトリを構成する場所

番号 | 場所 | 概要 |
---|---|---|
1 | リモートリポジトリ (Remote Repository) | GitHubなどのサーバー上に存在するリポジトリ 複数人での共同作業や、コードのバックアップとして利用される |
2 | ローカルリポジトリ (Local Repository) | ファイルの変更履歴を保存する場所 テージングエリアにある変更内容が git commit コマンドによって、ひとかたまりの更新履歴(コミット)として記録される |
3 | リモート追跡ブランチ (Remote-tracking Branch) | ローカルリポジトリ内に存在し、リモートリポジトリのブランチの状態を追跡するための特殊なブランチ origin/main のような名前で表現され、直接編集することはできない ネットワークを介した操作(git fetchなど)によって自動的に更新される |
4 | ワーキングディレクトリ (Working Directory) | 現在作業しているファイルやディレクトリが存在する場所 実際にコードを編集したり、ファイルを追加・削除したりする領域 |
5 | ステージングエリア (Staging Area / Index) | ワーキングディレクトリでの変更のうち、次のコミットに含めたいものを一時的に置いておく場所 作業中の変更の中から、特定のまとまりだけを選んでコミットすることができる |
それでは、基本的なワークフローに沿って、リポジトリがどのように動作していくのかを見ていきましょう。
チーム開発の基本サイクル
チーム開発における基本的なワークフローは、以下のサイクルの繰り返しとなります。
- 作業を始める前に、まずリモートの最新状態を確認・取得する。(
clone
,fetch
,pull
)
他のメンバーの作業内容を自分のローカルに取り込み、常に最新の状態から作業を開始します。 - 自分のローカルで作業を進め、コミットする。
これは第1章 Git の基本、第2章 git branch/mergeで学んだ通りです。ぜひ、そちらをご覧ください。 - 作業がキリの良いところまで進んだら、その成果をリモートに送信する。(
push
)
これにより、あなたの変更がチームメンバーに共有されます。
この「Pull (Fetch) → ローカルで作業 → Push」というサイクルが、チーム開発の基本リズムとなります。
作業開始の準備(git clone)と、作業の共有(git push)の流れを、リポジトリを構成する場所のレベルで解説しています。コマンドを使った際の、具体的な流れをしっかりと理解してください。
git cloneの流れ

- リポジトリの全データ取得
git clone を実行すると、リモートリポジトリから、全データ(コミット履歴、すべてのブランチ情報を含む)をダウンロードし、ローカルに .git ディレクトリ(ローカルリポジトリ)を作成します。 - リモート追跡ブランチの作成
リモートリポジトリに存在する各ブランチ(例: main, develop)に対応する「リモート追跡ブランチ」がローカルリポジトリ内に作成されます。これらは origin/main や origin/develop といった名前で、リモートの状態を示すブックマークのような役割となります。 - ローカルブランチの作成と追跡設定
次にGitは、リモートリポジトリのデフォルトブランチ(通常はmain)と同じ名前の「ローカルブランチ」を自動的に作成します。そして、この新しく作られたローカルブランチ (main) が、対応するリモート追跡ブランチ (origin/main) を「追跡(track)」するように設定されます。 - ワーキングディレクトリへの展開(チェックアウト)
最後に、ステップ3で作成されたローカルブランチ (main) の内容をワーキングディレクトリに展開(チェックアウト)します。これにより、あなたのPCのフォルダ内に、プロジェクトのファイルが実際に格納され編集できるようになります。
git pushまでの流れ

- git fetch (もしくはgit pull ):
他の人がリモートリポジトリを更新した可能性があるので、最新情報を取得してリモート追跡ブランチを更新します。 - git merge (もしくはgit pull ):
リモートの変更を自分の作業ブランチに取り込みます。 - git add:
コミットしたい変更をステージングエリアに追加します。 - git commit:
ステージングした内容をローカルリポジトリに記録します。 - git push:
自分のローカルリポジトリの変更をリモートリポジトリに送信し、チームに共有します。
【pull
とfetch
、どっちを使う?】
初心者のうちは「まずfetch
して他の人の変更内容を確認し、問題なければ自分のブランチにmerge
する」という丁寧な手順がおすすめです。慣れてきたら、fetch
とmerge
を一度に行うpull
を使うと効率的です。まずは安全なfetch
から慣れていきましょう。
コマンド実践ガイド:こんな時どう使う?
1. git remote add <name> <URL>
:リモートリポジトリを登録する
概要
ローカルリポジトリに対して、連携先となるリモートリポジトリの場所を「ショートカット名(通常はorigin
)」を付けて登録します。git clone
で始めた場合は自動で登録されるため、この操作は不要です。
利用事例
git init
で手元で作成したプロジェクトを、後からGitHub上に作成した空のリポジトリに接続したい。
実行手順
- GitHub上で新しいリポジトリを作成し、そのリポジトリのURLをコピーします。
- ローカルリポジトリのディレクトリで、以下のコマンドを実行します。
# 'origin' という名前でリモートURLを登録(HTTPSを使う場合)
git remote add origin https://github.com/user/repo.git
git remote -v
を実行して、登録が正しく行われたか確認できます。
コマンドの実行例:リモートリポジトリの登録(SSHキー利用)
# 'origin' という名前でリモートURLを登録(SSHキーを使う場合)
git remote add origin git@github.com:hogehoge/hello-world.git
# 変更をGitHubにプッシュ
git push -u origin main
2. git fetch
: リモートの様子を”覗き見”する安全なコマンド
概要
リモートリポジトリの最新の履歴を、ローカルリポジトリにダウンロードします。このコマンドの重要な点は、ダウンロードするだけで、あなたの作業ブランチ(main
など)にはまだ統合しないということです。他の人の進捗を、自分の作業に影響を与えることなく安全に確認できます。
利用事例
- 他のメンバーがどのような変更を行ったか、自分の作業と統合する前に確認したい。
実行手順
git fetch origin
実行後、origin/main
のような「リモート追跡ブランチ」が更新されます。git log origin/main
とすることで、リモートのmain
ブランチの最新履歴を確認できます。
コマンドの実行例:git fetch(リモートリポジトリの履歴を取り込む)
# git fetchでリモートリポジトリの情報を取得
hogehoge@mac hello-world % git fetch origin
Enter passphrase for key '/Users/hogehoge/.ssh/id_ed25519':
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 1), reused 0 (delta 0), pack-reused 0 (from 0)
Unpacking objects: 100% (3/3), 933 bytes | 311.00 KiB/s, done.
From github.com:hogehoge/hello-world
995b187..2954a14 main -> origin/main
3. git pull
: リモートの変更を自分の作業に”取り込む”コマンド
概要
チーム開発で最も頻繁に使うコマンドの一つです。リモートの最新の履歴をダウンロードし、それを現在の作業ブランチに自動でマージします。内部的にはgit fetch
とgit merge
を連続して実行しています。
利用事例
- 朝、出社して作業を始める前に、チームの最新の変更を自分の環境に反映させたい。
実行手順
main
ブランチで作業している場合、以下のコマンドを実行します。
git pull origin main
注意点
自分もリモートも同じファイルの同じ箇所を変更していた場合、マージコンフリクトが発生します。その際は、第2章で学んだ手順に従ってコンフリクトを解決してください。
コマンドの実行例:git pull(リモートリポジトリのファイルマージでコンフリクト発生のケース)
# git pullでリモートリポジトリのファイルをマージ(コンフリクト発生のケース)
hogehoge@mac hello-world % git pull origin main
Enter passphrase for key '/Users/hogehoge/.ssh/id_ed25519':
From github.com:hogehoge/hello-world
* branch main -> FETCH_HEAD
hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint:
hint: git config pull.rebase false # merge
hint: git config pull.rebase true # rebase
hint: git config pull.ff only # fast-forward only
hint:
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
fatal: Need to specify how to reconcile divergent branches.
hogehoge@mac hello-world %
4. git push
: 自分の作業をチームに”共有”するコマンド
概要
ローカルリポジトリで行ったコミットを、リモートリポジトリにアップロードします。この操作によって、初めてあなたの変更がチームメンバーに共有されます。
利用事例
- 機能開発が完了したので、自分の作業ブランチをGitHubにプッシュして、プルリクエストを作成したい。
実行手順
`feature/a-branchブランチでの作業をリモートに送信する場合、以下のコマンドを実行します。
git push origin feature/a-branch
注意点
もし他の人が先に同じブランチを更新していた場合、push
は拒否されます。これは、Gitが他の人の変更履歴を誤って上書きしてしまう「履歴の書き換え」を防ぐための安全機能です。
エラーメッセージが表示されたら、慌てずにまずgit pull
(またはgit fetch
& git merge
)でリモートの最新の変更を取り込み、ローカルで統合してから、再度push
を試みてください。
# 現在のローカルリポジトリの状態を確認
hogehoge@mac hello-world % git status
On branch feature/a-branch
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: README.md
modified: index.html
no changes added to commit (use "git add" and/or "git commit -a")
# 変更したファイル(コンフリクトを解消してマージ済み)をステージング&コミット
hogehoge@mac hello-world % git add .
hogehoge@mac hello-world % git commit -m "fix:conflict"
[feature/a-branch 25202a8] fix:conflict
2 files changed, 2 insertions(+), 1 deletion(-)
hogehoge@mac hello-world % git status
On branch feature/a-branch
nothing to commit, working tree clean
# 変更したブランチをリモートリポジトリにプッシュ
hogehoge@mac hello-world % git push origin feature/a-branch
Enter passphrase for key '/Users/hogehoge/.ssh/id_ed25519':
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 8 threads
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 828 bytes | 828.00 KiB/s, done.
Total 7 (delta 2), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (2/2), completed with 1 local object.
remote:
remote: Create a pull request for 'feature/a-branch' on GitHub by visiting:
remote: https://github.com/hogehoge/hello-world/pull/new/feature/a-branch
remote:
To github.com:hogehoge/hello-world.git
* [new branch] feature/a-branch -> feature/a-branch
hogehoge@mac hello-world %
5. 【上級者向け】git push --force-with-lease
:ローカルの履歴で強制上書きする
概要
rebase
などでローカルのコミット履歴を書き換えた場合、リモートの履歴との間に矛盾が生じるため、通常のpush
はできなくなります。このコマンドは、リモートの履歴をローカルの履歴で強制的に上書きします。
--force
との違い: 通常の--force
は、他の人が行った変更も問答無用で消し去ってしまう危険があります。--force-with-lease
は、自分が知らない変更がリモートにプッシュされていない場合に限り、上書きを実行するため、より安全です。- 【警告】 このコマンドはチームで共有しているブランチ(
main
など)には絶対に、絶対に、使用しないでください。 他のメンバーの変更を消し去ってしまう、非常に危険な操作です。個人で開発しているブランチを、プルリクエスト作成前にrebase
で綺麗に整えた、というような限定的な状況でのみ、意味を完全に理解した上で使用してください。初心者のうちは、このようなコマンドが存在する、ということだけ知っておけば十分です。
6. 【応用】git clone --depth 1
: プロジェクトの最新版だけを素早く取得する
概要
リポジトリの全履歴を含めず、最新の1コミット分だけの状態でリポジトリをクローンします。
利用事例
- リポジトリの過去の歴史は不要で、最新のソースコードだけをすぐに手に入れたいとき。
- (応用例)CI/CDパイプライン(自動でテストやビルドを行う仕組み)の中で、処理時間を短縮したいとき。
参考資料
- Pro Git Book – リモートでの作業
- Git公式ドキュメント
まとめ
本記事では、チーム開発におけるGitの心臓部とも言えるリモート操作、特にgit fetch
, git pull
, git push
に焦点を当てて解説しました。
チーム開発の基本リズムは、「①fetch
で確認 → ②merge
(またはpull
)で更新 → ③ローカルで作業・commit
→ ④push
で共有」 のサイクルです。
特に初心者のうちは、いきなりpull
するのではなく、まずfetch
して変更内容を確認する癖をつけることで、予期せぬコンフリクトを減らし、落ち着いて作業を進めることができます。
push
が拒否されたら、それは他の誰かが先に更新した合図です。慌てずにpull
(またはfetch
& merge
)して、最新の状態に追いついてから再度push
しましょう。
この記事で解説した知識と手順は、あなたを「Gitが怖い」状態から「Gitを使いこなせる」チームの一員へと導く、確かな一歩です。恐れずにコマンドを打ち、チーム開発への自信を深めていってください。
さあ、あなたのMacを快適な開発環境にしましょう!!