【Git】git pull でブランチを指定する方法をわかりやすく解説

はじめに

皆さんがGitを使って開発しているとき、複数のブランチが存在するプロジェクトを扱う場面は多いでしょう。

メインブランチや機能ブランチ、バグ修正用のブランチなど、状況に応じてさまざまなブランチを並行して管理するのが一般的です。

このとき、ブランチ単位で新しい変更を取り込む必要がありますが、慣れないうちは「どのように指定すればよいか分からない」と戸惑うことがあるかもしれません。

そこで、今回は git pull でブランチを指定する方法 を中心に、基本的な流れや実務的な注意点をまとめていきます。

Gitの初心者がつまずきやすいポイントを押さえながら、実務で役に立つ活用シーンまでをわかりやすく紹介しますので、ぜひ参考にしてみてください。

この記事を読むとわかること

• git pull と ブランチ指定 の基礎知識
• 「リモートブランチ」と「ローカルブランチ」の違い
• ブランチを指定して pull する実践的な手順
• 実務で遭遇しやすいケースと注意点

git pull とは何か

Gitの基本操作の中で、リモートリポジトリ にある変更を手元に取り込む際に使うコマンドの一つが git pull です。

git pull は内部的に git fetch と git merge をまとめて実行するものと考えると理解しやすいでしょう。

• git fetch：リモートリポジトリにある最新のコミット情報を取得し、ローカルリポジトリに持ってくる
• git merge：取得したコミットをローカルブランチに統合する

この2つのステップを自動で行うのが git pull です。

ただし、pull の前に自分が作業中のブランチを正しく把握していなかったり、必要なブランチに切り替えていなかったりすると、誤ったブランチに変更を反映してしまうことがあります。

そのため、作業対象となる 「ブランチをしっかり指定して pull する」 というのは、効率的でミスの少ない開発環境を作るうえで欠かせません。

リモートブランチとローカルブランチ

ブランチを扱うときは、まずリモートブランチとローカルブランチの2種類がある点を押さえておく必要があります。

リモートブランチ：GitHubなどのリモートリポジトリ上に存在するブランチ

例：origin/main、origin/feature/login など

ローカルブランチ：自分の開発環境（ローカルリポジトリ）に存在するブランチ

例：main、feature/login など

実務のシーンでも、チームメンバーがリモートリポジトリにプッシュした変更を取り込むために、リモートブランチとローカルブランチをどう対応させるかが重要です。

もし「origin/feature/login」というリモートブランチに新しいコミットがある場合、それをローカル環境の「feature/login」にマージして取り込む、という手順になります。

このとき、ローカルブランチが存在しない状態でも リモートブランチを指定して pull すれば、自動で新しいローカルブランチを作ることも可能です。

ただし、それを把握していないと、意図しないブランチに変更を取り込んだり、競合が発生して困ってしまうこともあるでしょう。

git pull ブランチ指定の基本的な書き方

それでは具体的に、git pull でブランチを指定する方法を見ていきましょう。

最もシンプルな例として、リモートリポジトリの origin という名前が付いたリモートの main ブランチを、手元の main ブランチに取り込む場合は次のようなコマンドになります。

コピー
git pull origin main

ここでそれぞれの意味を整理します。

• origin：リモートリポジトリのエイリアス名（初期設定で origin が一般的）
• main：pull したい対象のリモートブランチ

ローカルで現在 main ブランチにいる場合、このコマンドを実行するとリモートの main の変更を取得し、現在のローカル main にマージします。

もしローカルブランチが別の場合、git checkout main などで切り替えるか、後述するように「存在しないブランチを作成する」手順を踏む必要があるでしょう。

よくある使用例：新しい機能ブランチを取り込みたい場合

チーム開発などでは、メインブランチ以外の機能ブランチや修正ブランチを取り込みたいケースも多いと思います。

たとえば、リモートブランチが origin/feature/user-profile として存在している状態で、ローカルに同名のブランチが存在しない場合を考えてみましょう。

以下のように git pull を実行することで、ローカルに feature/user-profile というブランチを新規作成し、その内容を取り込むことができます。

コピー
git checkout -b feature/user-profile origin/feature/user-profile
git pull origin feature/user-profile

1行でまとめるときは次のコマンドでも作成可能です。 ただ、明示的にブランチを切り替えてから pull する方が手順を分かりやすくできます。

コピー
git pull origin feature/user-profile:feature/user-profile

上記のように「リモートブランチ:ローカルブランチ」の形式で指定すると、もしローカルブランチが存在しない場合には作成し、そこにマージされます。

ただし、慣れないうちはブランチ名を間違えやすいので、まずは git checkout -b の方法で慎重に作業する方が混乱を減らすポイントです。

pull の前に気をつけたいポイント

ここでは、実際にブランチ指定を使う前に押さえておきたい注意点をいくつか取り上げます。

ブランチの作業内容をコミットする

作業中のブランチに未コミットのファイルが残っている状態で git pull すると、競合が起きたり、予期せぬマージが発生したりするリスクがあります。

必ず作業中の変更をコミットしてから pull を実行する習慣をつけるとよいでしょう。

どのブランチに取り込むのかを確認する

pull した後で「思っていたのと違うブランチにマージしてしまった…」となることは意外とよくあります。

• 現在どのローカルブランチにいるのか
• pull するリモートブランチはどれか

この2点を確認してからコマンドを打つようにしましょう。

リモートとローカルのブランチ対応を確認する

Gitはブランチの切り替えと管理を柔軟に行えますが、リモートのブランチ名とローカルのブランチ名が必ずしも一致するとは限りません。

たとえば、ローカル側では feature/design-update という名称で開発していたけれど、リモートには feature/design-2025-update というブランチがある場合などです。

そのため、リモートブランチとローカルブランチの対応関係 を日頃から把握しておくと、マージのトラブルを減らせます。

実務での活用シーン

ここでは、よくある開発フローの中で「git pull ブランチ指定」を活用するシーンをいくつか紹介します。

チームメンバーの作業を反映させる

チームメンバーが新しい機能を開発し、リモートにプッシュしたら、他のメンバーがそのブランチを取り込むタイミングがあります。

たとえば「origin/feature/search-function」というブランチで検索機能を追加したとき、他のメンバーは以下のようにして反映を取り込みます。

コピー
git checkout main
git pull origin main

git checkout -b feature/search-function origin/feature/search-function
git pull origin feature/search-function

まずメインブランチを最新にしてから機能ブランチを新規作成、さらに pull で内容を反映させる流れです。

開発が完了した後は、この機能ブランチをメインブランチにマージするなどの工程が続きます。

リリース前の最終チェック

複数のブランチが並行して開発されている場合、リリース直前にはメインブランチやリリース用のブランチを最新の状態にして、テストや動作確認を行うでしょう。

リリースブランチが「origin/release/1.2.3」で管理されている場合は、ローカルに release/1.2.3 が存在するかを確認し、なければ新規でブランチを作成して pull します。

こうすることで、本番リリースに向けて最新のソースを素早く手元に持ってきて検証できるというわけです。

緊急バグ修正を取り込む

本番環境でバグが見つかり、緊急対応を行ったケースでも「git pull ブランチ指定」は非常に便利です。

たとえば、セキュリティ修正用に hotfix/security-patch というブランチが切られていたら、次のようにしてローカルにも反映します。

コピー
git checkout main
git pull origin main
git checkout -b hotfix/security-patch origin/hotfix/security-patch
git pull origin hotfix/security-patch

バグ修正が完了したブランチを取り込んだら、テスト後にメインブランチへマージしてリリースしていく流れになります。

リモートブランチを確認するコマンド

ブランチを指定して pull する前に、そもそもリモートリポジトリにどのようなブランチが存在しているかを確認する方法として git branch -r が便利です。

コピー
git branch -r

これを実行すると、origin/main や origin/feature/xxx といったリモートブランチの一覧を表示してくれます。

もし新規に pull したいブランチがリストに含まれていない場合は、git fetch origin で最新のリモートブランチ情報を取得してみるとよいでしょう。

git pull でブランチ指定を使うメリット

改めて、なぜわざわざブランチを指定した pull を行うのか、メリットを簡単にまとめてみます。

明確なブランチ管理ができる

pull 先を指定することで、どのブランチの変更を取り込んでいるか明確になります。

誤操作を防ぎやすい

デフォルトの git pull は、現在チェックアウトしているブランチのトラッキング先を自動で参照します。
しかし、意図しないブランチで pull してしまうリスクがあるので、ブランチを明示できると安全です。

新規ローカルブランチをすばやく作成可能

リモートブランチを指定して pull すれば、まだローカルになかったブランチを一度の操作で作成しつつ内容を反映できます。

トラブルシューティング：競合が発生したら

pull によって変更を取り込んだ際、ファイルの同じ箇所をローカルとリモートで同時に修正していた場合などに 競合（コンフリクト） が発生することがあります。

競合が起きた場合の大まかな流れは次のとおりです。

1. 競合しているファイルをエディタで開き、どの部分が競合しているかを確認する
2. 必要に応じて修正点を手動でまとめる（ローカル側かリモート側、あるいは両方の内容を活かすなど）
3. 競合部分を解消したらファイルを保存し、git add してからコミットし直す

この競合解消作業は、開発者なら避けては通れません。

git pull ブランチ指定 を活用しても競合は起こりうるので、もし競合が出たら落ち着いて修正内容を吟味しましょう。

よくある疑問

初心者の方が持ちそうな疑問をいくつか取り上げてみます。

git pull --rebase との違いは？

git pull --rebase は、リモートブランチのコミットをマージではなくリベースの形で適用するオプションです。

ブランチの履歴が直線的になる反面、コミットの履歴が書き換わるため、共同開発では使い方に注意が必要です。

単純に「最新の変更をローカルに反映したい」だけなら、まずは普通の git pull origin ブランチ名 を使うのがおすすめです。

git fetch とどう違うの？

git fetch はリモートの変更履歴を取得するだけで、ローカルブランチには反映しません。

一方、git pull は fetch と merge を一度にやってしまうイメージです。

ブランチ指定の pull は「fetch したブランチの内容を自動でマージする」という点に違いがあります。

ブランチ指定しない pull はダメなのか？

必ずしもダメではありません。

特定のブランチを追跡する設定がされていれば、git pull だけで問題なくリモートの変更を取り込めるでしょう。

ただ、複数のブランチが並行しているチーム開発では、明示的に pull するブランチを指定する方が混乱を防ぎやすいというメリットがあります。

まとめ

Gitで開発を進める上では、複数のブランチを使い分けて作業する場面が多くあります。

その際、git pull ブランチ指定 をしっかりと把握しておくと、リモートリポジトリからの変更を安全かつスムーズに取り込むことができます。

• リモートブランチとローカルブランチの関係を理解する
• pull する前に作業中のブランチを確認し、未コミットは残さない
• 新規の機能ブランチがあれば明示的にブランチを作ってから pull する

こういったポイントを押さえておくと、チーム開発における混乱やエラーを減らしやすくなります。

慣れてくれば、ブランチ指定 は特に難しい操作ではありません。

ぜひ日々の開発で活用し、より快適なバージョン管理ライフを送ってみてください。