READMEの説明を直したい。でも、チームが使っている状態に、作業途中の修正を混ぜたくない。そんなときに使うのが、Gitの「ブランチ」です。
ブランチを使うと、ある時点の履歴から作業の流れを分けて、変更をコミットしながら進められます。完成した変更は、内容を確認して別のブランチへ取り込めます。
この記事では、前回の「コミット・ステージング」に続いて、ブランチの役割と基本操作を学びます。講義の文字起こしではなく、Git公式資料をもとにした入門記事です。
1. ブランチは、コミットを指す名前
Gitは、コミットによってプロジェクトの状態を履歴に残します。ブランチは、その履歴にあるコミットを指す、移動可能な参照です。初心者の段階では「作業の流れにつけた名前」と考えると理解しやすくなります。
たとえば、mainというブランチからfeature/readme-guideというブランチを作ると、最初は両方とも同じコミットを指します。その後、修正用のブランチでコミットすると、そのブランチが新しいコミットを指すようになります。mainの指す先は、その操作だけでは変わりません。Git公式：ブランチの仕組み
mainは、中心となるブランチによく使われる名前です。ただし、特別な機能を持つ名前ではありません。プロジェクトによってはmasterや別の名前を使います。
ブランチを作るだけで、プロジェクト全体を別フォルダーにコピーするわけではありません。まず増えるのは、コミットを指す名前です。
→作成時：両ブランチが指す同じコミット
→作成時：両ブランチが指す同じコミット
→修正用ブランチでコミット後：元のコミット
→修正用ブランチでコミット後：新しいコミット
→修正用ブランチでコミット後：元のコミット
→修正用ブランチでコミット後：新しいコミット
2. なぜ作業を分けるのか
ブランチを使う目的は、変更の目的ごとに作業を進め、取り込む内容を確認しやすくすることです。
たとえば、次のように作業を分けられます。名前はこの記事の例です。
| ブランチの名前 | 作業の目的 |
|---|---|
main |
チームで共有する基準の履歴 |
feature/readme-guide |
READMEに使い方の説明を追加する |
fix/broken-link |
記事にあるリンク切れを修正する |
READMEの説明を考え直す作業と、急いで直したいリンク切れを別々に進めれば、どちらを先に取り込むかを判断しやすくなります。Gitの公式入門でも、通常の開発とは別のブランチで緊急修正を行う例が紹介されています。Git公式：基本的なブランチとマージ
ただし、ブランチを分ければ自動的に品質が保証されるわけではありません。動作確認やレビューは必要です。また、ブランチの作成だけでアクセス権や公開サイトの表示が切り替わるわけでもありません。公開との関係は、そのプロジェクトの運用によって決まります。
3. 作成と切り替えは、別の操作
ブランチを「作る」ことと、そのブランチへ「切り替える」ことは別です。
git branch feature/readme-guideこのコマンドはブランチを作成しますが、作業中のブランチは切り替わりません。Git公式：git branch
作成済みのブランチへ切り替えるには、次のコマンドを使います。
git switch feature/readme-guide新しいブランチを作って、そのまま切り替えたい場合は、次のように書けます。
git switch -c feature/readme-guide-cを付けると、現在の位置からブランチを作成して切り替えます。通常の切り替えでは、選んだブランチの状態に合わせて、作業ツリーとステージングエリアが更新されます。Git公式：git switch
ここでいう作業ツリーは、普段ファイルを開いて編集している場所です。同じフォルダーでブランチを切り替えると、追跡対象のファイルの内容が変わることがあります。「ブランチごとのファイルを、別々のフォルダーで常に見ている」と考えないようにしましょう。
4. READMEの修正を、別のブランチで進める
ここからは、ローカルの練習用リポジトリを想定した例です。mainが存在し、作業ツリーに未コミットの変更がなく、feature/readme-guideはまだ存在しないものとします。
手順1：現在の状態を確認する
git status作業中のブランチと、未コミットの変更の有無を確認します。すでに修正したファイルがある場合は、次の節の注意点を読んでから切り替えます。
手順2：基準のブランチから作業を分ける
git switch main
git switch -c feature/readme-guideこの順番なら、現在のmainの位置から修正用ブランチを作れます。チーム作業では、基準のブランチを更新する手順など、そのチームのルールにも従ってください。
手順3：READMEを編集して、コミットする
READMEに「記事原稿はarticlesフォルダーに保存します」という説明を追加し、ファイルを保存したとします。
git diff
git add README.md
git diff --staged
git commit -m "READMEに記事原稿の保存場所を追加"
git status変更を確認し、ステージングで記録する内容を選び、コミットします。最後の状態確認では、意図せず残った変更がないかを見ます。このコミットは、現在作業しているfeature/readme-guideの履歴を進めます。Git公式：変更の記録
手順4：mainへ切り替えて、違いを見る
git switch mainほかの操作をしていないこの例では、READMEは修正前の状態に戻ります。追加した説明が消えたように見えても、修正用ブランチのコミットには残っています。そのブランチへ再び切り替えれば、記録した説明を確認できます。
- 前提：mainが存在／未コミットの変更なし／修正用ブランチは未作成前提に沿って開始 ↓
- git status：現在のブランチと変更を確認状態を確認 ↓
- git switch main：基準へ切り替え現在のmainから作業を分ける ↓
- git switch -c feature/readme-guide：作成して切り替え修正用ブランチで編集 ↓
- READMEに保存場所の説明を追加して保存保存後に確認 ↓
- git diff：変更を確認記録する内容を選択 ↓
- git add README.md：記録する内容を選ぶ選択内容を確認 ↓
- git diff –staged：ステージングした変更を確認変更を記録 ↓
- git commit：修正用ブランチの履歴を進める残った変更を確認 ↓
- git status：意図せず残った変更を確認基準の状態との違いを見る ↓
- git switch main：この例ではREADMEが修正前の状態に戻る修正用ブランチへ再び切り替えれば説明を確認できる ↓
- 説明は修正用ブランチのコミットに残る
5. 未コミットの変更は、自動でブランチに収納されない
「ブランチを切り替えれば、作業途中の変更も前のブランチに保存される」と考えると、混乱しやすくなります。
未コミットの変更がある状態で切り替えると、変更を持ったまま別のブランチへ移動できる場合があります。一方、切り替えによってその変更が失われるおそれがある場合は、Gitが操作を拒否します。切り替えに成功したことと、変更が履歴へ記録されたことは別です。Git公式：git switchの説明
初心者のうちは、切り替える前にgit statusを確認し、必要な変更を現在のブランチでコミットしておくと整理しやすくなります。まだコミットしたくない作業には、一時的に退避するgit stashという方法もあります。Git公式：作業の退避
Gitが切り替えを拒否したときは、まず表示されたメッセージを読み、どのファイルに変更があるかを確認してください。変更を捨てるオプションを、意味がわからないまま使わないことが大切です。
6. 完成した変更を取り込むのが、マージ
別のブランチで進めた変更を取り込む操作が、マージです。取り込み先のブランチへ切り替えてから、取り込みたいブランチを指定します。
先ほどのローカルの練習を続けるなら、次のようになります。
git switch main
git merge feature/readme-guideこの場合は、mainへREADMEの修正を取り込みます。取り込む方向を逆にしないように、実行前に現在のブランチを確認しましょう。Git公式：git merge
マージの結果は、履歴の分かれ方によって異なります。取り込み先が進んでいない場合は、ブランチの指す先を進める「ファストフォワード」で済むことがあります。履歴が分かれている場合は、マージコミットが作られることがあります。同じ箇所に競合する変更があると、自動ではまとめられず、内容の確認と修正が必要です。Git公式：基本的なマージ
チームの共有ブランチへ取り込む場合は、Pull Requestやレビューなど、決められた手順を使ってください。上のコマンドは、手元の練習でマージの方向を理解するための例です。GitHubへ変更を送るpushや、本番環境への公開は、別の操作です。
→git merge feature/readme-guide：READMEの修正をmainへ取り込む
→ファストフォワード：ブランチの指す先を進める
→マージコミットが作られることがある
→競合：自動ではまとめられない
→内容の確認と修正が必要
7. ブランチとworktreeの違い
通常、1つの作業フォルダーでは、ブランチを切り替えながら作業します。「修正前と修正後を、別々のフォルダーで同時に開きたい」という場合には、Git worktreeという仕組みが役立ちます。
worktreeを使うと、同じリポジトリに複数の作業ツリーを持てます。たとえば、基準の状態を確認するフォルダーと、修正作業をするフォルダーを並べて使えます。通常、同じブランチを複数の作業ツリーで同時にチェックアウトすることは制限されます。Git公式：git worktree
整理すると、ブランチは「履歴を分ける名前」、worktreeは「別の場所で作業するための作業ツリー」です。
| 仕組み | 役割 |
|---|---|
| ブランチ | 履歴を分ける名前 |
| worktree | 別の場所で作業するための作業ツリー |
最初は1つのフォルダーでブランチを切り替える方法を学び、同時作業が必要になったらworktreeを学ぶと理解しやすくなります。
8. まとめと理解度確認
ブランチを使うと、基準の履歴から作業を分けて、変更をコミットしながら進められます。作成、切り替え、コミット、マージは、それぞれ役割の違う操作です。
| 操作 | 役割 |
|---|---|
| ブランチを作る | コミットを指す新しい名前を作る |
| ブランチを切り替える | 作業するブランチを選ぶ |
| コミットする | 選んだ変更を記録し、現在のブランチを進める |
| マージする | 別の履歴の変更を、現在のブランチへ取り込む |
自分の言葉で説明してみる
- 新しいブランチを作ると、プロジェクト全体が別フォルダーにコピーされますか？
git branch feature/readme-guideだけで、作業するブランチは切り替わりますか？- 未コミットの変更があるとき、ブランチを切り替えれば必ず保存されますか？
- 修正用ブランチの変更をmainへ取り込むには、どちらへ切り替えてからマージしますか？
- 2つのブランチの内容を、別フォルダーで同時に開きたい場合に使える仕組みは何ですか？
解答例
- コピーされません。まず、コミットを指す新しい参照が作られます。
- 切り替わりません。切り替えには
git switchを使います。作成と切り替えをまとめるならgit switch -cです。 - 必ず保存されるわけではありません。変更を持ったまま移動する場合や、操作が拒否される場合があります。履歴へ記録するにはコミットが必要です。
- 取り込み先のmainへ切り替えてから、修正用ブランチを指定してマージします。
- Git worktreeです。
参考資料
- Git公式：ブランチの仕組み
- Git公式：基本的なブランチとマージ
- Git公式：git branch
- Git公式：git switch
- Git公式：変更の記録
- Git公式：作業の退避
- Git公式：git merge
- Git公式：git worktree
資料確認日：2026年10月11日
コメント