チーム開発でGitを使っていると、「他のメンバーが作成したリモートブランチをローカルに持ってきて作業を始めたい」という場面に頻繁に遭遇します。慣れてしまえば何気ない操作ですが、fetch・checkout・trackingの関係を正しく理解していないと、意図しないブランチで作業してしまったり、pushやpull時にエラーが出たりすることがあります。本記事では、この一連の手順を体系的に整理してお伝えします。
そもそもリモートブランチとは何か
手順に入る前に、「リモートブランチ」という概念を改めて整理しておきましょう。Gitは分散型バージョン管理システムであり、各開発者のローカル環境とリモートリポジトリ（GitHubやGitLabなど）はそれぞれ独立したリポジトリとして存在しています。
リモートブランチとは、リモートリポジトリ上に存在するブランチのことです。一方、ローカルでリモートの状態を参照するために保持されるのが「リモート追跡ブランチ（remote-tracking branch）」で、origin/main や origin/feature/user-auth といった形式で表示されます。
この区別は意外と重要です。たとえば origin/feature/user-auth はリモートそのものではなく、「最後にfetchした時点でのリモートのfeature/user-authブランチの状態」を表しています。つまり、fetchしなければローカルのリモート追跡ブランチは古いままということです。
# リモートリポジトリの情報を確認
git remote -v出力例：
origin git@github.com:your-org/your-repo.git (fetch)
origin git@github.com:your-org/your-repo.git (push)複数のリモートを登録している場合は、origin 以外にも upstream や fork などが表示されます。チーム開発では通常 origin のみで運用するケースが多いですが、オープンソースプロジェクトへのコントリビューションでは複数リモートを使い分けることもあります。
リモートブランチを取得するfetchの役割と使い方
Gitで他のメンバーが作成したブランチを取得する最初のステップは git fetch です。ここで重要なのは、fetchはリモートリポジトリの情報をローカルにダウンロードするだけで、作業ディレクトリには一切影響を与えないという点です。
# リモートの最新情報をすべて取得
git fetch origin
# 特定のブランチだけを取得したい場合
git fetch origin feature/user-authfetchを実行すると、ローカルには origin/feature/user-auth のようなリモート追跡ブランチが作成・更新されます。この段階ではあくまで「リモートの状態を知った」だけであり、自分の作業ブランチとしてはまだ存在していません。
筆者自身、Git を使い始めた頃は git pull との違いがよく分からず、とりあえずpullしていた時期がありました。しかしpullはfetchとmerge（またはrebase）を同時に行うコマンドです。意図しないマージが発生するリスクを避けるためにも、まずfetchで情報を取得し、内容を確認してから次のステップに進む習慣をつけることをお勧めします。
fetchとpullの違いを具体的に比較する
言葉だけでは分かりにくいので、具体的なシナリオで違いを見てみましょう。
たとえば、あなたがローカルの main ブランチで作業中に、リモートの main にも新しいコミットがpushされたとします。
# fetchの場合：リモートの情報を取得するだけ
git fetch origin
# この時点でローカルのmainは変わらない
# origin/mainだけが更新される
git log --oneline main..origin/main # リモートにあってローカルにないコミットを確認この git log main..origin/main というコマンドは非常に便利です。fetchした後にリモートでどのような変更があったかを、マージ前に安全に確認できます。差分の内容まで見たい場合は git diff main..origin/main を使います。
# pullの場合：取得と統合を一度に行う
git pull origin main
# fetchとmerge（またはrebase）が一気に実行される
# コンフリクトが発生すると、その場で解消が必要pullは手軽ですが、「今どんな変更が入ってくるのか」を確認する余地がありません。小規模なチームや変更量が少ない場合はpullで十分ですが、大規模なプロジェクトや重要なブランチでは、fetchで確認してからmergeするという二段階の手順のほうが安全です。
リモートブランチの一覧を確認する
リモートブランチの一覧を確認するには、以下のコマンドが便利です。
# リモートブランチの一覧を表示
git branch -r
# ローカルとリモートの両方を表示
git branch -a出力例：
origin/main
origin/develop
origin/feature/user-auth
origin/feature/payment-api
origin/fix/login-errorブランチ数が多いプロジェクトでは、grepと組み合わせて絞り込むと効率的です。
# featureブランチだけを表示
git branch -r | grep feature/
# 特定のメンバー名で絞り込む（ブランチ名に名前が含まれる場合）
git branch -r | grep tanaka同じように「fetchしたはずなのにブランチが見えない」と悩んでいる方も多いのではないでしょうか。その場合は git fetch --prune を試してみてください。リモートで削除済みのブランチ参照がローカルに残っていると、一覧が煩雑になり、目的のブランチを見つけにくくなることがあります。
# リモートで削除されたブランチの参照をローカルからも削除
git fetch --prune origin
# 毎回自動的にpruneするように設定することも可能
git config --global fetch.prune trueこの fetch.prune の設定は一度入れておくと本当に快適です。チーム開発ではブランチがどんどん作られては削除されるため、ローカルに古い参照が溜まりがちです。筆者も以前、リモートではとっくに削除されたブランチを誤ってcheckoutしてしまい、古いコードをベースに作業してしまったことがありました。
checkoutでローカルブランチを作成して切り替える
fetchでリモートブランチの情報を取得できたら、次はローカルブランチを作成して作業を開始します。ここで使用するのが git checkout または git switch です。
# リモートブランチと同名のローカルブランチを作成して切り替え
git checkout feature/user-auth実はこのコマンドには、Gitの便利な自動処理が組み込まれています。ローカルに feature/user-auth というブランチが存在せず、かつリモートに origin/feature/user-auth が1つだけ存在する場合、Gitは自動的にリモート追跡ブランチに基づくローカルブランチを作成してくれます。この挙動は「DWIMモード（Do What I Mean）」と呼ばれています。
成功すると、以下のようなメッセージが表示されます。
branch 'feature/user-auth' set up to track 'origin/feature/user-auth'.
Switched to a new branch 'feature/user-auth'このメッセージが出れば、ローカルブランチの作成とトラッキングの設定が同時に完了しています。
ただし、複数のリモートを設定している環境では、この自動判別が正しく動作しないことがあります。そのような場合は、明示的にリモート追跡ブランチを指定しましょう。
# 明示的にリモート追跡ブランチを指定して作成
git checkout -b feature/user-auth origin/feature/user-authGit 2.23以降で導入された git switch コマンドを使う方法もあります。checkoutはブランチの切り替えとファイルの復元という2つの異なる機能を持っており、switchはブランチ操作に特化したコマンドとして分離されました。
# switchコマンドでの同様の操作
git switch feature/user-auth
# 明示的に作成する場合
git switch -c feature/user-auth origin/feature/user-authcheckoutとswitchの使い分け
checkoutとswitchのどちらを使うかはチームの方針次第ですが、新しいプロジェクトではswitchを採用するケースが増えてきていると感じます。一概にどちらが優れているとは言えない部分もありますので、チーム内で統一しておくとよいでしょう。
両者の違いをもう少し具体的に整理します。
# checkoutの二面性：ブランチ切り替えとファイル復元を兼ねる
git checkout feature/user-auth # ブランチ切り替え
git checkout -- index.html # ファイルの変更を破棄（復元）
# switch + restoreで役割を分離
git switch feature/user-auth # ブランチ切り替え
git restore index.html # ファイルの変更を破棄（復元）git checkout でファイル名とブランチ名が衝突すると意図しない動作が起きるリスクがあります。たとえば main という名前のファイルがリポジトリに存在する場合、git checkout main がブランチ切り替えなのかファイル復元なのか曖昧になります。git switch と git restore ではこの曖昧さが排除されています。
よくあるエラーとその対処法
ローカルブランチの作成時に遭遇しやすいエラーと対処法も押さえておきましょう。
エラー1：同名のローカルブランチが既に存在する場合
fatal: a branch named 'feature/user-auth' already exists
この場合は、既存のブランチに切り替えるだけで済みます。
git switch feature/user-auth
# リモートの最新を取り込みたい場合
git pullエラー2：未コミットの変更がある状態で切り替えようとした場合
error: Your local changes to the following files would be overwritten by checkout:
src/auth.ts
Please commit your changes or stash them before you switch branches.作業中の変更を一時退避するには git stash を使います。
# 変更を一時退避
git stash
# ブランチを切り替え
git switch feature/user-auth
# 作業が終わったら元のブランチに戻ってstashを復元
git switch -
git stash popgit stash は「ちょっとだけ別ブランチを確認したい」という場面で非常に重宝します。ただし、stashを溜め込みすぎると何をstashしたのか分からなくなるため、git stash list で定期的に確認する習慣をつけておくと安心です。
trackingの設定と確認方法を理解する
ローカルブランチとリモートブランチの紐づけを「トラッキング（upstream tracking）」と呼びます。前述のcheckoutやswitchで自動作成した場合は、トラッキングも自動で設定されます。しかし、手動でブランチを作成した場合や、トラッキングが切れてしまった場合には、明示的に設定し直す必要があります。
# 既存のローカルブランチにupstreamを設定
git branch --set-upstream-to=origin/feature/user-auth feature/user-auth
# 短縮形
git branch -u origin/feature/user-authトラッキングが正しく設定されているかどうかは、以下のコマンドで確認できます。
# 各ブランチのトラッキング情報を表示
git branch -vv出力例は次のようになります。
main a1b2c3d [origin/main] 最新のコミットメッセージ
* feature/user-auth e4f5g6h [origin/feature/user-auth] 認証機能の実装ブランチ名の横に [origin/feature/user-auth] のように表示されていれば、トラッキングが設定されています。この設定があることで、git pull や git push を引数なしで実行でき、日常の操作が格段にスムーズになります。
最初はトラッキングの概念を見落としていたのですが、これを理解してからは「pushするたびにリモートブランチ名を指定する」という手間がなくなり、作業効率が明らかに向上しました。
トラッキングが設定されていない場合のエラー
トラッキングの重要性が実感できるのは、設定されていないときにエラーに遭遇した瞬間です。
git pushfatal: The current branch feature/user-auth has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin feature/user-authこのエラーメッセージは親切にも解決策を提示してくれています。指示に従って --set-upstream（短縮形は -u）をつけてpushすれば、トラッキングの設定とpushが同時に行えます。
# pushと同時にトラッキングを設定
git push -u origin feature/user-auth筆者のチームでは、新しくブランチを作成した際の最初のpushには必ず -u をつけるルールにしています。この一手間を惜しまないことで、以降のpush/pullがスムーズになります。
トラッキング情報の詳細を確認する
git branch -vv よりもさらに詳しい情報が必要な場合は、以下のコマンドも活用できます。
# 特定ブランチのトラッキング情報を詳細に表示
git status -sb出力例：
## feature/user-auth...origin/feature/user-auth [ahead 2, behind 1]
M src/auth.tsこの出力から、ローカルがリモートより2コミット先行しており（ahead 2）、リモートにはローカルにない1コミットがある（behind 1）ことが分かります。この情報は、pushやpullの前にローカルとリモートの差分状況を把握するのに役立ちます。
実務で使える一連のワークフローまとめ
ここまでの内容を踏まえ、リモートブランチを取得してローカルで作業を開始するまでの実践的なワークフローを整理します。
# 1. リモートの最新情報を取得（不要な参照も整理）
git fetch --prune origin
# 2. 目的のリモートブランチが存在するか確認
git branch -r | grep feature/user-auth
# 3. ローカルブランチを作成して切り替え
git switch feature/user-auth
# 4. トラッキングが正しく設定されているか確認
git branch -vv
# 5. 作業を進め、コミット後にpush
git add .
git commit -m "認証ロジックの修正"
git pushこの手順を一通り身につけておけば、チーム開発においてリモートブランチとのやり取りで迷うことはほとんどなくなるはずです。
注意点として、長期間更新していないブランチで作業を再開する場合は、作業前に git pull でリモートの最新変更を取り込むことを忘れないようにしてください。コンフリクトが発生した場合も、fetchで最新状態を把握してから対処するほうが安全です。
作業再開時のワークフロー
しばらく放置していたブランチで作業を再開する場面も実務では多いものです。その際のワークフローも整理しておきます。
# 1. 現在のブランチと状態を確認
git status
git branch -vv
# 2. リモートの最新を取得
git fetch --prune origin
# 3. 目的のブランチに切り替え
git switch feature/user-auth
# 4. リモートの最新変更をローカルに取り込む
git pull
# 5. mainブランチの最新変更も取り込んでおく（コンフリクトの早期発見）
git merge origin/mainステップ5は見落とされがちですが、非常に重要です。長期間更新していないブランチは、mainブランチとの差分が大きくなっていることがあります。作業を進めてからコンフリクトに気づくよりも、作業再開時にmainの最新を取り込んでおくほうが、解消の手間が少なく済みます。
もしコンフリクトが発生した場合は、慌てずに以下の手順で対処します。
# コンフリクトしているファイルを確認
git status
# エディタでコンフリクト箇所を修正した後
git add <修正したファイル>
git commit -m "mainブランチとのコンフリクトを解消"複数ブランチを効率よく切り替えるテクニック
チーム開発では、レビュー依頼を受けて他のメンバーのブランチを確認したり、自分の作業ブランチに戻ったりと、頻繁にブランチを切り替えることがあります。以下のテクニックを知っておくと便利です。
# 直前のブランチに戻る（cdの「cd -」と同じ感覚）
git switch -
# 最近のブランチ切り替え履歴を確認
git reflog | grep "checkout:"git switch - は、2つのブランチを行き来する場面で驚くほど重宝します。「レビュー用ブランチを確認して、自分のブランチに戻る」という操作がワンコマンドで完結します。
トラブルシューティング：現場でよくある問題と解決策
ここまでの手順を理解していても、実際のチーム開発ではさまざまなトラブルに遭遇します。筆者がこれまでの開発経験で実際に出会った問題と、その解決策をまとめました。
「ブランチが見つからない」と言われる
fetchしたつもりなのに、ブランチが見つからないケースです。
git switch feature/payment
# error: invalid reference: feature/paymentまず、ブランチ名が正しいか確認しましょう。ブランチ名のtypoは意外と多い原因です。
# ブランチ名の一部で検索
git branch -r | grep payment
# 出力例：もしかしてこのブランチ？
# origin/feature/payment-apiブランチ名に -api が付いていた、というのはよくある話です。また、メンバーがまだブランチをpushしていない可能性もあります。その場合はメンバーに確認しましょう。
リモートブランチが削除されたのにローカルに残っている
チーム開発では、マージ済みのブランチがリモートで削除されることがあります。しかし、ローカルのリモート追跡ブランチは自動では削除されません。
# 削除済みのリモートブランチを整理
git fetch --prune origin
# ローカルブランチも整理したい場合（マージ済みのものを一覧表示）
git branch --merged main
# 確認してから削除
git branch -d feature/old-featuregit branch --merged main は、mainにマージ済みのブランチを一覧表示します。これらは基本的に削除しても問題ないブランチです。ただし、削除前に一覧を確認し、意図しないブランチが含まれていないか必ずチェックしてください。
detached HEAD状態になってしまった
リモート追跡ブランチを直接checkoutすると、「detached HEAD」という状態になります。
# これはやってはいけない（detached HEADになる）
git checkout origin/feature/user-authYou are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.この状態でコミットしても、どのブランチにも属さないコミットが作成されてしまいます。もしこの状態になってしまったら、以下のように対処します。
# ローカルブランチを作成してdetached HEADから抜ける
git switch -c feature/user-auth
# すでにコミットしてしまった場合も、同じコマンドで救済できる
git switch -c feature/user-auth筆者も最初の頃、origin/ をつけたままcheckoutしてしまい、この状態に陥ったことがあります。コミットしたはずの変更が消えたように見えて焦りましたが、reflogから復旧できました。Gitはほとんどの操作を取り消せるように設計されているので、慌てずに対処することが大切です。
Git設定で日常の操作をさらに快適にする
ここまで紹介してきた操作をさらに快適にするために、筆者が実際に設定しているGitの設定をいくつかご紹介します。
# fetchを実行するたびに自動的にpruneする
git config --global fetch.prune true
# pushのデフォルト挙動を「現在のブランチと同名のリモートブランチにpush」に設定
git config --global push.default current
# pullをrebaseモードにする（マージコミットを作らない）
git config --global pull.rebase true
# ブランチの一覧をソート（最近使ったブランチを上に表示）
git config --global branch.sort -committerdate特に push.default current は便利な設定です。この設定をしておくと、新しいブランチで最初にpushする際に git push -u origin feature/user-auth と入力しなくても、git push -u origin だけで同名のリモートブランチが作成されます。
また、branch.sort -committerdate を設定すると、git branch の出力が最近操作したブランチ順にソートされます。多くのブランチを抱えるプロジェクトでは、これだけで目的のブランチを見つけやすくなります。
まとめ：基本操作の理解がチーム開発の質を高める
fetch・checkout・trackingは、Gitのブランチ運用における基本中の基本です。しかし、振り返ると基本であるからこそ曖昧なまま使い続けていた時期があり、それが小さなトラブルの原因になっていたと気づかされました。
それぞれの役割を整理すると、fetchは「リモートの情報をローカルに安全に取得する」、checkoutやswitchは「ローカルブランチを作成・切り替えする」、trackingは「ローカルとリモートのブランチを紐づけてpush/pullを簡潔にする」という明確な役割分担があります。
本記事で紹介したコマンドやワークフローの中から、まずは基本の流れ──git fetch --prune origin → git switch ブランチ名 → git branch -vv で確認──を日々の開発に取り入れてみてください。この3ステップが体に馴染んでくると、チーム開発でのブランチ操作に迷うことはほとんどなくなるはずです。
トラブルに遭遇したときも、Gitは操作の履歴を reflog にしっかり記録してくれています。慌てず、現在の状態を git status や git branch -vv で確認し、一つずつ対処していけば、たいていの問題は解決できます。
これらの基本操作を正確に理解し、チーム全体で共有することが、日々の開発をスムーズに進めるための土台になるのではないでしょうか。
aduceでは、Git運用を含む開発プロセス全体の最適化や、チーム開発体制の構築をIT顧問サービスとして支援しています。開発ワークフローの改善やチームの技術力向上にお悩みの方は、ぜひこちらからお気軽にご相談ください。