Git ブランチ (git branch) の作り方・切り替え方を初心者向けに解説
はじめに
Gitはソフトウェア開発の現場で広く使われているバージョン管理システムです。
ファイルの変更履歴を安全に管理し、チームでの共同作業もスムーズに行える点が多くの開発者に支持されています。
その中でもブランチという機能は、作業内容を独立した領域で進められる強力な仕組みです。
新しい機能の開発やバグ修正など、同じプロジェクトで同時並行的に複数の作業を進めたいときに役立ちます。
ただし、初めてGitを触る方にとってはブランチの概念がやや抽象的で、どのように作って切り替えれば良いのか混乱しがちです。
そこで本記事では、Gitブランチの作り方や切り替え方を初心者の方でも理解しやすいように解説します。
実務で開発を行うときのシナリオを交えながら、コマンドの具体例やトラブルシューティングのポイントを紹介します。
これを読めば、ブランチを使った開発フローを自信を持って始められるようになるのではないでしょうか。
この記事を読むとわかること
- Gitブランチの基本的な仕組みとメリット
- ブランチの具体的な作り方
- ブランチの切り替え方と注意点
- 実務でよく使われるブランチ運用のパターン
- コンフリクト解消やよくあるエラーの対処法
Gitブランチの概要
Gitブランチとは何か
Gitのブランチは、変更履歴の“枝”を作る仕組みと考えるとわかりやすいです。
一つのメインラインから枝分かれする形で新しい作業用の履歴を作り、その作業が完了したらメインラインに統合します。
例えば、メインの状態をそのままに、新しい機能だけを分岐した別ラインで作業できるので、誤って動いている機能を壊したり、実行に影響を与えたりするリスクが下がります。
また、メインラインをきれいに保ったまま、複数の機能を同時に並行開発できることもメリットの一つです。
なぜブランチが必要なのか
特に複数人での開発現場では、作業同士が衝突することを避けるためにもブランチがほぼ必須といえます。
メインライン（多くの場合は main や master と呼ぶことが多いです）に常に安定した状態を保ちたいなら、ブランチ上で新機能を開発・テストした後に問題がなければ統合（マージ）します。
この方法によって、本番運用中のコードや他のメンバーの作業内容に悪影響を及ぼさないように開発を進めることができます。
結果的に、コミュニケーションロスや手戻りのリスクを最小限に抑えられるのです。
作業の同時進行とブランチ
チーム開発であれば、Aさんは新しい機能を、Bさんはバグ修正を同時に行うケースがよくあります。
その際、同じリポジトリの中で別々のブランチを使えば、AさんとBさんが互いに作業を邪魔し合うことなく進められます。
実務の現場では、feature/xxx という名前のブランチを作って1機能ごとに作業したり、hotfix/xxx といったブランチ名で緊急の修正を適用することがあります。
使い終わったブランチはメインラインに統合したあと、不要になれば削除してリポジトリを整理することも多いです。
Git ブランチを作成する手順
事前準備: リポジトリの状態を確認
最初に、作業中のGitリポジトリが問題なく動いているかを確認しましょう。
例えば、作成途中のファイルや未コミットの変更があると、切り替え時にエラーや競合が発生しやすくなります。
以下のコマンドで作業ツリーの状態をチェックすることが多いです。
変更が残っている場合はコミットしておくか、必要に応じて変更を取り消してください。
git status
もし一時的に作業内容を退避したい場合は、git stash コマンドを使ってローカルの変更を隠す方法があります。
stashを適用するまで変更が保存されるので、ブランチを切り替える前に状態をきれいにしておくのに便利です。
git branch コマンドを使ったブランチ作成
Gitでブランチを新しく作成する際、もっとも基本となるコマンドが git branch です。
たとえば develop という名前のブランチを作りたい場合は以下のように入力します。
git branch develop
実行後、まだブランチ develop に切り替わっているわけではありません。
新しいブランチはリポジトリ内で「枝」として定義されただけの状態です。
今いるブランチは引き続き main （または master）のままになっています。
ブランチが実際に作成されたかどうかは次のコマンドで確認できます。
git branch
実行すると、手元にあるブランチの一覧が表示され、現在いるブランチには * が付いています。
もし develop が新しく追加されていれば成功です。
git checkout -b で同時に作成と切り替え
ブランチを作成してから切り替えるまでの手順をまとめると、以下のようになります。
git branch developでブランチ作成git checkout developでブランチ切り替え
ただし、これらを一度に行う方法として、git checkout -b [ブランチ名] がよく使われます。
つまりコマンド一発でブランチ新規作成と同時に切り替えが完了します。
git checkout -b develop
この操作によって、develop ブランチが存在しない場合は自動的に作成され、さらに作成直後にそこへ移動します。
何度もコマンドを打たなくてもいいので、初心者の方にもわかりやすいでしょう。
GUIツールでのブランチ作成
コマンドラインを使わない方法として、VS CodeやGitHub Desktop、SourcetreeなどのGUIツールで簡単にブランチを作成・切り替えできる機能があります。
画面の「New Branch」や「Branch作成」などのボタンをクリックすると、現在のブランチから派生するブランチを作成できます。
初心者の方は視覚的にブランチの分岐がわかりやすいので、慣れるまではGUIツールを利用するのも有効です。
ただし、コマンドラインでの操作を覚えておくと、SSH接続先のサーバーなどGUIが使えない環境でも柔軟に対応できるメリットがあります。
Git ブランチを切り替える方法
git checkout で切り替える
作成済みのブランチに移動するには、まず git checkout コマンドがよく使われてきました。
たとえば develop というブランチへ移動したい場合は以下のように入力します。
git checkout develop
切り替えが成功すると、Switched to branch 'develop' のようなメッセージが表示されます。
git branch コマンドで確認すると、* develop のようにアスタリスクが表示されているはずです。
この操作によって、ローカルの作業フォルダは develop ブランチの状態に切り替わります。
もし以前コミットしていない変更がある場合は、チェックアウトがブロックされたり、エラーが表示されるケースがあるので気をつけましょう。
git switch で切り替える
Gitのバージョンが更新されるにつれ、ブランチの切り替え専用コマンドとして git switch が推奨されるようになってきています。
git checkout はブランチ切り替え以外にもファイルの変更を破棄する操作など複数の意味を持っていたため、初心者にとっては少しわかりにくい面がありました。
git switch コマンドを使えば、ブランチの切り替えが明確に表現されます。
以下の例では develop ブランチに移動します。
git switch develop
新しいブランチを作りながら切り替える場合は、-c オプションを使います。
git switch -c develop
これにより git checkout -b develop と同様の動きをします。
近年はこちらのほうがよりブランチ操作に特化した書き方として認識されています。
ブランチ切り替えにおける注意点
ブランチを切り替える前に、ローカルで未コミットの変更が残っていないかを確認してください。
未コミットの変更が存在するまま別のブランチに移動すると、競合が起きる場合や意図しない変更が混ざってしまう場合があります。
どうしても未コミットの状態のまま別ブランチへ移動しなければならないときは、git stash コマンドで変更を一時的に退避させるのが有効です。
stash された変更はあとで git stash pop などで復元できます。
また、ブランチ名はわかりやすく付けることが大切です。
あいまいな名前だと、複数人で作業する際にどんな作業を行うブランチなのか分からなくなりやすいです。
実務でのブランチ切り替えシーン
たとえば、テスト担当者から「この機能が動かない」と指摘があり、急ぎでバグ修正をしたいケースを考えてみましょう。
現在進めている別の作業はコミットかstashで退避し、hotfix/bugfix-001 のような新しいブランチを作ります。
修正が終われば、hotfix/bugfix-001 をメインブランチにマージして問題を解決し、次に戻ってきたときには、途中だった作業ブランチへ改めて git switch [作業ブランチ名] などで戻ります。
このように場面ごとに素早く切り替えることができるのはブランチの大きな利点です。
実務での活用シーン: ブランチ運用戦略
フィーチャーブランチモデル
たとえば、機能単位でブランチを作る運用をフィーチャーブランチモデルと呼ぶことがあります。
主に main（または master）ブランチから派生して、1つの新機能につき1つのブランチを作り、開発が完了したらテストを行い、問題なければメインブランチにマージする流れです。
このように機能ごとにブランチを独立させることで、他の機能と干渉しない状態で開発を進められます。
さらに、コードレビューの時点でも差分が明確なので、誰がどの部分を担当しているかがわかりやすいです。
リリースブランチとホットフィックス
リリース前の安定バージョンを管理するためにリリースブランチを用意することもあります。
本番リリース前に機能追加をストップし、品質向上のためにバグ修正だけを行う期間がある場合は、リリースブランチで確認・修正を集中して行います。
また、緊急対応が必要な不具合が見つかったときは、hotfix と呼ばれるブランチを切って対処するのが一般的です。
完成したらメインブランチだけでなく、開発中のブランチ（たとえば develop）にも修正を反映させることで、再度同じバグが出現しないようにしておきます。
mainブランチとdevelopブランチ
有名な運用例としてGitflowというモデルがあります。
これはメインとなるmain ブランチ (または master) と、開発を集約するdevelopブランチの2本を軸にして、そこから派生するfeature、release、hotfixなどのブランチを使い分ける方法です。
- main (master): リリース用の安定版を管理
- develop: 現在開発中の最新コードを管理
- feature: 新機能を開発するときに作るブランチ
- release: リリース前の最終調整に使うブランチ
- hotfix: 本番環境の緊急バグ修正に使うブランチ
このように役割をはっきりさせて運用すると、メンバー間で「どこに何をマージするか」が明確になり、混乱を防げます。
チーム開発でのブランチ命名規則
複数人が同じリポジトリを操作する場合、命名規則をあらかじめ決めておくとスムーズです。
たとえば以下のように、役割ごとに頭文字をつけます。
- feature/xxx: 新機能の開発用
- bugfix/xxx: バグ修正用
- hotfix/xxx: 緊急修正用
- release/xxx: リリース調整用
内容を表す文字列（たとえば機能名やチケット番号など）をブランチ名に含めることで、外部のプロジェクト管理ツールと連携しやすくなります。
Gitのコミットメッセージにも同じチケット番号を入れておくと、変更履歴とタスク管理の紐付けがより明確になります。
マージとコンフリクト解消
ブランチを統合するマージの基本
ブランチで独立して開発した内容が完成したら、メインブランチへ統合（マージ）します。
以下のコマンドは、feature/awesome-feature ブランチを develop ブランチに統合するときの例です。
1. develop ブランチに移動:
git checkout develop
2. マージ実行:
git merge feature/awesome-feature
この操作で、feature/awesome-feature ブランチが含んでいるコミットの内容が develop に加わります。
もし衝突がなければ、そのままコミットが完了し、マージが終了します。
コマンドラインでのマージの流れ
マージが終わったら git status で作業ツリーを確認し、問題がなければ git push などでリモートリポジトリに反映させます。
チーム開発では、GitHubやGitLab上でプルリクエスト（MR）を作成してレビューを受ける流れが一般的です。
レビューアーが内容を確認し、問題なければGitHubやGitLabのUI上で「Merge」ボタンを押すとマージが行われます。
このとき、ローカルでもブランチの同期を行う必要があります。
git fetch や git pull を適時実行し、最新の状態を常に保ちながら作業するといいでしょう。
コンフリクトが起きたときの対処
複数のブランチで同じファイルの同じ行を変更した場合、Gitがどちらの変更を正解とすべきかわからなくなることがあります。
これがいわゆる「コンフリクト（衝突）」です。
コンフリクトが発生すると、マージ時に警告メッセージが表示されます。
該当ファイル内には独特の記号（<<<<<< HEAD など）とともに衝突部分が示されるので、手動で正しい内容を選択・統合してください。
コンフリクトを解消したら、その修正をコミットすればマージは完了です。
この作業をこまめに行うことで、大きな衝突を未然に防ぎやすくなります。
マージコミットを避けるrebaseについて
ブランチを統合するときに、マージコミットが増えすぎると履歴が複雑になると感じる場面があります。
そこで、rebase という方法を使うと、履歴をきれいに並べ替えながらブランチを統合できることがあります。
たとえば、feature ブランチをメインブランチに取り込む際に git rebase main などを実行すると、メインブランチの最新コミットに対して、feature 側のコミットを一連の流れとして積み直す形になります。
この方法では、ブランチが「どこで分岐してどこで合流したのか」が見えにくくなる反面、コミット履歴が一本に整う利点があります。
ただし、rebaseはブランチの履歴を書き換える操作なので、チームでの使い方については慎重にルールを決めると良いでしょう。
誰かが既に共有しているブランチをrebaseすると、他の人のローカル履歴と食い違いが起きる可能性があります。
よくあるエラーと対処法
"error: Your local changes to the following files would be overwritten by checkout"
これは、現在のブランチで未コミットの変更が残っているのに、別のブランチへチェックアウトしようとしたときに起きやすいエラーです。
ファイルが上書きされてしまう可能性があるため、Gitは安全のためチェックアウトを拒否します。
解決策としては、変更内容をコミットするか、不要な変更なら git checkout -- [ファイル名] などで破棄した上で、再度ブランチを切り替えてみてください。
一時的に変更を退避したい場合は、git stash を使ってから切り替える方法もあります。
"fatal: Not a git repository"
Gitリポジトリのルートディレクトリでもない場所、あるいはGit管理されていないディレクトリでGitコマンドを実行した場合に表示されるエラーです。
プロジェクトのトップディレクトリに移動しているか確認し、.git フォルダがある場所でコマンドを使ってみてください。
マージコンフリクト（Merge conflict）
先ほど解説したように、別ブランチで同じ行を変更しているなどの場合に発生します。
衝突部分を手動で修正し、コンフリクトマーカーを取り除いてから改めてコミットしましょう。
ツールによってはGUIでコンフリクト解消を支援してくれるので、初心者の方はそちらを活用するのも良いでしょう。
"detached HEAD"
ブランチ以外の特定のコミットに直接チェックアウトした場合に起きやすい状態です。
「このコミットの状態を一時的に確認したい」という場面で使われることがありますが、コミットを追加してもブランチに紐づかないため、意図せず操作すると困惑しやすいです。
もし間違ってdetached HEAD状態になった場合は、新しいブランチを切ってそこに作業内容を保存することができます。
git switch -c [新ブランチ名] などを行えば、後からマージやプッシュがしやすくなります。
まとめ
Gitのブランチは、プロジェクトの変更を並行して安全に進められる便利な仕組みです。
新機能の開発、バグ修正、リリース前の調整など、あらゆる作業を独立した枝に分けることで、メインのコードを壊さずに試行錯誤が可能になります。
本記事では、ブランチの基本概念から具体的な作成・切り替えコマンド、そして実務での活用シーンやトラブルシューティングのポイントを紹介しました。
いずれも、初心者の方が戸惑いやすい部分を中心に解説していますので、まずは小さなプロジェクトで試しながら学んでみてください。
一度ブランチ運用に慣れると、複数人が同じリポジトリで作業していても、コードの混乱を最小限に抑えやすいと感じられるでしょう。
ぜひご自身の開発現場でもブランチを活用して、効率的かつ安全なバージョン管理を実現してください。