2026年10月8日にGitのbranch、switch、commit、add、merge公式マニュアルを再確認した。branchは履歴上の参照を作り、switchは作業対象を切り替え、addは次のcommitへ内容を準備し、commitは履歴へ保存し、mergeは複数の履歴を結合する。作業ツリー、staging、履歴、共有、レビュー、競合、承認を別の状態として扱い、記事の図や例は自作教材で実際のリポジトリの安全を保証しない。
ブランチは、Gitで作業の続きを指し示す名前です。新しい機能を試すたびにプロジェクト全体を別フォルダーへコピーする代わりに、履歴のどこから作業するかを名前で管理します。ただし、ブランチを作っただけで変更の衝突や誤公開を防げるわけではありません。
30秒で要点
- ブランチはコミットを指す参照。作成、切替、コミット、統合は別の操作です。
- HEADで現在の作業先を確認します。未コミットの変更は、ブランチを変えれば自動保存されるものではありません。
- 目的を絞った名前を付け、差分確認とテストを済ませてから統合します。公開はさらに別の工程です。
道の分岐を「名前と履歴」で考える
ブログに新しいボタンを付ける例で考えます。mainがコミットAを指しているとき、feature/new-buttonを作ると、最初は両方がAを指します。作成時点で新しいコミットが増えるわけではありません。featureへ切り替え、変更をコミットしてBを作ると、featureはBへ進み、mainはAのままです。git-branchの公式説明も、作成と切替を別の操作として扱っています。
図のAとBは説明用の記号です。同じAを指す名前が2つあっても、コミットは1つです。Bを追加した後は名前2つ、コミット2つになります。「ブランチ数」と「保存された変更の数」を混同しないための小さな確認です。
HEADは通常、現在のブランチを指します。切り替えると作業ツリーとindexも対象に合わせて更新されます。ローカル変更が失われる切替は通常拒否されますが、未コミット変更があれば必ず拒否されるわけではありません。変更を持ったまま別ブランチへ移れる場合もあります。切替前の確認は省略しないでください。git-switchでこの条件を確認できます。
作成、変更、統合を順に体験する
以下は、最初のコミットがあり、現在のブランチがmainの練習用リポジトリ向けです。実務のリポジトリでは、保存先・現在地・未コミット変更を確認してから操作します。設定や秘密情報を含むフォルダーを練習に使わないでください。
1. 作成してから切り替える
git status --short
git branch --show-current
git branch feature/new-button
git branch --show-current
git switch feature/new-button
git branch --show-current作成直後の表示はmainのまま、switch後はfeature/new-buttonです。git branch ブランチ名は作成、git checkout ブランチ名は従来から使われる切替です。今回の例ならgit checkout feature/new-buttonでも切り替えられます。
新規作成と切替を一度に行う別表現はgit switch -c feature/new-buttonです。旧来のgit checkout -b feature/new-buttonも同じ目的で使います。既に同名ブランチを作った後に、これらの作成コマンドを重ねて実行しないでください。ここでは先ほどの2段階の手順を採用します。
2. 変更を選んでコミットする
練習用のbutton.txtを編集・保存した後、次の順に確認します。
git diff
git add button.txt
git diff --cached
git commit -m "新規ボタン機能を追加"
git log -1 --onelinegit add .は現在のディレクトリ以下の対象をまとめてstageします。今回は変更を選びやすいようファイル名を指定しました。commitが記録するのはstage済みの内容です。編集中のすべてが自動で記録されるわけではありません。git-addとgit-commitが、この2段階の根拠です。
3. 統合先を確認してから取り込む
featureの差分と動作を確認し、作業ツリーを整理してからmainへ戻ります。この練習ではmainに別のコミットを追加していない前提です。
git checkout main
git merge --ff-only feature/new-button
git status --short元のgit merge feature/new-buttonや一般形のgit merge ブランチ名も、現在のブランチへ指定履歴を取り込む操作です。ここでは分岐した履歴を勝手に統合しないよう--ff-onlyを明示しました。拒否されたら強制するのでなく、履歴の分岐を確認します。mainへ取り込めても、サーバーへの公開や他メンバーへのpushが済んだ意味にはなりません。
名前は用途を伝えるための約束
Gitには「feature専用のブランチ型」はありません。次はチームで合意できる命名例です。
表が収まらない場合は、横にスクロールできます
| 作業の目的 | 名前の例 | 区切り方の考え方 |
|---|---|---|
| デザインの試作 | feature/new-design、experiment/新デザイン試行 | 採用するか未定の実験を識別する |
| 新機能 | feature/payment、feature/search、feature/authentication | 決済・検索・認証を一度に混ぜない |
| 利用者向け機能 | feature/product-search、feature/user-login、feature/shopping-cart | レビューできる変更単位にする |
| 不具合修正 | fix/login-error、fix/payment-bug、bugfix/ログインエラー修正 | 症状や対象を特定できる名前にする |
| 緊急修正 | hotfix/security-patch、hotfix/critical-bug | 緊急でも確認・承認を省略しない |
feature/機能名、fix/バグ名は置換用の型であり、そのまま使う指定ではありません。feature/ユーザー登録機能のような日本語名を使うかは、周辺ツールも含めて決めます。testやnewだけでは目的を読み取りにくくなります。
mainとmasterは名前です。名前だけで保護・公開先・品質が決まることはありません。ホスティング側の保護ルール、レビュー、CI、デプロイの設定を別々に確認します。
チームで困らないための判断
表が収まらない場合は、横にスクロールできます
| 状況 | 最初に確認すること | 避けたい操作 |
|---|---|---|
| 切替で拒否された | 現在地と未コミット差分を確認し、必要な内容を保全する | 内容を見ずに強制破棄する |
| 同じファイルを複数人が編集 | 変更意図と担当範囲を共有し、短い単位でレビューする | branchを分けたから競合しないと思う |
| ブランチが増えた | 統合済みか、他者が使っていないか確認する | 未統合の作業を強制削除する |
| 小さな個人開発 | 目的ごとの短い作業branchから始める | 大規模な運用規則を無条件で導入する |
統合済みの練習ブランチを片付けるなら、別ブランチへ移った後のgit branch -d feature/new-buttonが通常の削除です。-Dは未統合でも削除できる強制指定なので、エラーを消すための代用品にしません。remoteのブランチ削除は別操作です。
プルリクエストは、GitHubなどのサービスで差分を相談・レビューする仕組みです。Gitのbranch作成コマンドそのものではありません。機能追加、ポートフォリオのデザイン、企業サイトの不具合修正でも、目的を分け、取り込む前に確認するという役割は共通です。