Gitでリモートブランチを取り込む基本！fetchとpullの使い分けをマスターしよう

こんにちは、とまだです。

みなさん、こんな経験はありませんか？

「チームメンバーが作ったブランチを自分のローカルに持ってきたいけど、どうすればいいの？」

「fetchとpullって何が違うの？いつ使い分ければいいの？」

私も最初はこの違いがよく分からず、適当にpullしてはコンフリクトに悩まされていました。

今回は、リモートブランチの取り込み方法を「図書館の本」に例えながら、初心者でも理解できるように解説していきます。

リモートブランチを「図書館の本」で理解する

リモートブランチとは、チームで共有している「図書館」にある本のようなものです。

図書館（リモートリポジトリ）には、みんなが読める本（ブランチ）がたくさん置いてあります。

自分の家（ローカル環境）で本を読むには、図書館から借りてくる必要がありますよね。

Gitでも同じように、リモートの変更を自分のローカルに持ってくる作業が必要になります。

なぜリモートブランチの取り込みが必要なのか

チーム開発では、メンバーがそれぞれ作業した成果をリモートリポジトリに送ります。

他のメンバーの作業内容を確認したり、最新のコードで開発を続けたりするためには、定期的にリモートブランチを取り込む必要があるんです。

これを怠ると、古いコードで作業を続けることになり、後でマージする時に大量のコンフリクトが発生してしまいます。

fetchとpullの違いを3分で理解

リモートブランチを取り込む方法は主に2つ。

fetchとpullです。

図書館の例で説明すると、こんな違いがあります。

fetch = 図書館の蔵書リストを更新

git fetch origin

fetchは「図書館にどんな新しい本があるか」の情報だけを取得します。

本の中身はまだ読めませんが、どんな本があるかは分かる状態です。

実際のコードでいうと、リモートの変更情報は取得しますが、自分の作業ブランチには反映されません。

pull = 本を借りて読む

git pull origin main

pullは「図書館から本を借りてきて、すぐに読める状態にする」イメージです。

fetchに加えて、自動的に現在のブランチにマージまで行います。

便利な反面、予期しないマージが発生することもあるので注意が必要です。

実践！リモートブランチの取り込み方

それでは、実際にリモートブランチを取り込む手順を見ていきましょう。

基本的な流れ

まず、リモートリポジトリの状況を確認します。

# リモートリポジトリの確認
git remote -v

# リモートの変更を取得
git fetch origin

# リモートブランチの一覧を表示
git branch -r

origin/feature/new-designというブランチが見つかったとしましょう。

これを自分のローカルに取り込むには以下のようにします。

# 新しくローカルブランチを作成して切り替え
git checkout -b feature/new-design origin/feature/new-design

これで、リモートブランチの内容がローカルで作業できるようになりました。

すでに存在するブランチを更新する場合

すでにローカルに同じ名前のブランチがある場合は、以下のように更新します。

# ブランチに切り替え
git checkout feature/new-design

# リモートの変更を取り込む
git pull origin feature/new-design

または、より慎重に進めたい場合は以下のようにします。

# fetchして確認
git fetch origin

# 差分を確認
git log HEAD..origin/feature/new-design

# 問題なければマージ
git merge origin/feature/new-design

実務でよくあるシーンと対処法

シーン1: mainブランチの最新を取り込みたい

開発中のブランチに、最新のmainブランチの変更を取り込む場合です。

# mainブランチに切り替え
git checkout main

# 最新の状態に更新
git pull origin main

# 作業ブランチに戻る
git checkout feature/my-feature

# mainをマージ
git merge main

定期的にこの作業を行うことで、大きなコンフリクトを避けられます。

シーン2: チームメンバーと同じブランチで作業

複数人で同じブランチを触る場合は、こまめな同期が重要です。

# 作業前に必ず最新を取得
git pull origin feature/shared-branch

# 作業...

# プッシュ前にも再度取得
git pull origin feature/shared-branch

# プッシュ
git push origin feature/shared-branch

シーン3: コンフリクトが発生した場合

pullした時にコンフリクトが発生することがあります。

# コンフリクトが発生
git pull origin main
# Auto-merging file.js
# CONFLICT (content): Merge conflict in file.js

この場合は、以下の手順で解決します。

1. エディタでコンフリクトファイルを開く
2. <<<<<<< HEADと>>>>>>>の間を手動で修正
3. 修正が終わったらステージング
4. コミットして完了

# コンフリクトを解決後
git add .
git commit -m "Resolve merge conflict"

よくあるトラブルと解決法

トラブル1: fast-forwardできない

# エラーメッセージ例
! [rejected]        main -> main (non-fast-forward)

これは、ローカルとリモートで履歴が分岐している時に発生します。

解決策は2つあります。

# 方法1: マージコミットを作成
git pull --no-rebase origin main

# 方法2: リベースで履歴を整理
git pull --rebase origin main

プロジェクトのルールに従って選択しましょう。

トラブル2: リモート追跡ブランチが設定されていない

# エラーメッセージ例
There is no tracking information for the current branch.

この場合は、追跡設定を追加します。

git branch --set-upstream-to=origin/feature/my-feature feature/my-feature

これで、今後はgit pullだけで済むようになります。

fetchとpullの使い分けのコツ

最後に、実務での使い分けのポイントをまとめます。

fetchを使うべき場面

• リモートの状況を確認したいだけの時
• 慎重に変更を取り込みたい時
• 複数のブランチの状態を一度に確認したい時

pullを使うべき場面

• すぐに最新の状態で作業を始めたい時
• 単純な更新で、コンフリクトの心配が少ない時
• 自分しか触っていないブランチを更新する時

まとめ

リモートブランチの取り込みは、チーム開発の基本中の基本です。

fetchとpullの違いを理解して、状況に応じて使い分けられるようになると、スムーズな開発ができるようになります。

特に重要なのは、定期的にリモートの変更を取り込む習慣をつけることです。

これだけで、多くのトラブルを未然に防げます。

最初は戸惑うかもしれませんが、何度も実践していけば必ず身につきます。

ぜひ今日から、積極的にリモートブランチの取り込みを実践してみてください！