【Git・GitHub操作ガイド】第5章 リモート操作:git fetch, git pull , git push の違いと使い分け

本記事の目的

「一人での開発は順調だったのに、チーム開発になった途端、Gitの使い方が分からなくなった…」
pullfetchって、何が違うの?」
「他の人のコードを消してしまったらどうしよう…」

Gitを学び始めたばかりのあなたが、チーム開発で最初にぶつかる壁が、リモートリポジトリとの連携ではないでしょうか。

この記事では、チーム開発の基本となるgit fetch, git pull, git pushについて、それぞれの違いと正しい使い分けを、図解と丁寧な解説でどこよりも分かりやすく説明します。

この記事を読めば、こんなことが分かります

  • git fetch, pull, pushの明確な違い
  • チーム開発での安全なGit操作サイクル
  • コンフリクトを未然に防ぐための考え方
  • 他のメンバーに迷惑をかけない、自信を持ったGit操作

自分のPC(ローカルリポジトリ)から、みんなの共有スペース(リモートリポジトリ)へ!

安全にコードをやり取りする技術を身につけ、チーム開発への不安を自信に変えましょう!


目次


対象読者

この記事は、特に以下のような方を対象としています。

  • Gitを学び始めたばかりで、pullfetchの違いがよく分からない方
  • 一人での開発経験はあるが、チーム開発は初めてで不安な方
  • チーム開発で他のメンバーに迷惑をかけないか、操作のたびに心配になる方

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)ワーキングディレクトリでの変更のうち、次のコミットに含めたいものを一時的に置いておく場所
作業中の変更の中から、特定のまとまりだけを選んでコミットすることができる

それでは、基本的なワークフローに沿って、リポジトリがどのように動作していくのかを見ていきましょう。


チーム開発の基本サイクル

チーム開発における基本的なワークフローは、以下のサイクルの繰り返しとなります。

  1. 作業を始める前に、まずリモートの最新状態を確認・取得する。(clone, fetch, pull)
    他のメンバーの作業内容を自分のローカルに取り込み、常に最新の状態から作業を開始します。
  2. 自分のローカルで作業を進め、コミットする。
    これは第1章 Git の基本第2章 git branch/mergeで学んだ通りです。ぜひ、そちらをご覧ください。
  3. 作業がキリの良いところまで進んだら、その成果をリモートに送信する。(push)
    これにより、あなたの変更がチームメンバーに共有されます。

この「Pull (Fetch) → ローカルで作業 → Push」というサイクルが、チーム開発の基本リズムとなります。
作業開始の準備(git clone)と、作業の共有(git push)の流れを、リポジトリを構成する場所のレベルで解説しています。コマンドを使った際の、具体的な流れをしっかりと理解してください。


git cloneの流れ

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

git pushまでの流れ

git pushまでの流れ

  1. git fetch (もしくはgit pull ):
    他の人がリモートリポジトリを更新した可能性があるので、最新情報を取得してリモート追跡ブランチを更新します。
  2. git merge (もしくはgit pull ):
    リモートの変更を自分の作業ブランチに取り込みます。
  3. git add:
    コミットしたい変更をステージングエリアに追加します。
  4. git commit:
    ステージングした内容をローカルリポジトリに記録します。
  5. git push:
    自分のローカルリポジトリの変更をリモートリポジトリに送信し、チームに共有します。

pullfetch、どっちを使う?】
初心者のうちは「まずfetchして他の人の変更内容を確認し、問題なければ自分のブランチにmergeする」という丁寧な手順がおすすめです。慣れてきたら、fetchmergeを一度に行うpullを使うと効率的です。まずは安全なfetchから慣れていきましょう。


コマンド実践ガイド:こんな時どう使う?

1. git remote add <name> <URL>:リモートリポジトリを登録する

概要

ローカルリポジトリに対して、連携先となるリモートリポジトリの場所を「ショートカット名(通常はorigin)」を付けて登録します。git cloneで始めた場合は自動で登録されるため、この操作は不要です。

利用事例

  • git initで手元で作成したプロジェクトを、後からGitHub上に作成した空のリポジトリに接続したい。

実行手順

  1. GitHub上で新しいリポジトリを作成し、そのリポジトリのURLをコピーします。
  2. ローカルリポジトリのディレクトリで、以下のコマンドを実行します。
# 'origin' という名前でリモートURLを登録(HTTPSを使う場合)
git remote add origin https://github.com/user/repo.git
  1. 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 fetchgit 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パイプライン(自動でテストやビルドを行う仕組み)の中で、処理時間を短縮したいとき。

参考資料


まとめ

本記事では、チーム開発におけるGitの心臓部とも言えるリモート操作、特にgit fetch, git pull, git pushに焦点を当てて解説しました。

チーム開発の基本リズムは、「①fetchで確認 → ②merge(またはpull)で更新 → ③ローカルで作業・commit → ④pushで共有」 のサイクルです。

特に初心者のうちは、いきなりpullするのではなく、まずfetchして変更内容を確認する癖をつけることで、予期せぬコンフリクトを減らし、落ち着いて作業を進めることができます。

pushが拒否されたら、それは他の誰かが先に更新した合図です。慌てずにpull(またはfetch & merge)して、最新の状態に追いついてから再度pushしましょう。

この記事で解説した知識と手順は、あなたを「Gitが怖い」状態から「Gitを使いこなせる」チームの一員へと導く、確かな一歩です。恐れずにコマンドを打ち、チーム開発への自信を深めていってください。

さあ、あなたのMacを快適な開発環境にしましょう!!

SNSでもご購読できます。

コメントを残す

*