Git ブランチ | git branch

git branch コマンド

ブランチとは、独立した開発ラインを意味する。ブランチは、Git の基本で説明した編集、ステージ、コミットのプロセスに対する抽象概念である。作業ディレクトリとステージング領域から、独立したプロジェクト履歴を作る手段だと考えることもできる。新しいコミットは現在のブランチの履歴に記録され、プロジェクト履歴の分岐を形成する。

git branch は、ブランチの作成、一覧表示、名前変更、削除を行うコマンドである。このコマンドには、ブランチを切り替える機能も、分岐した履歴を統合する機能も、変更を取り消す機能もない。そのため git branch は、多くの場合 git checkout や git merge と一緒に使われる。

使い方

git branch

リポジトリ内のすべてのブランチを一覧表示する。

git branch <branch>

<branch> という名前の新しいブランチを作成する。新しく作成されたブランチは自動的にはチェックアウトされない。

git branch -d <branch>

指定したブランチを削除する。ブランチに未マージの変更が残っている場合、Git は削除を拒否するため、このコマンドは安全な操作である。

git branch -D <branch>

指定したブランチに未マージの変更が残っていても、強制的に削除するコマンドである。特定の開発ラインで作成されたすべてのコミットを完全に削除したい場合に使う。

git branch -m <branch>

現在のブランチ名を <branch> に変更する。

補足説明

Git では、ブランチは日常的な開発プロセスの要素である。新機能の開発やバグ修正を行う場合、その規模にかかわらず変更をカプセル化するブランチを作成する。これにより、不安定なコードがメインコードベースへ直接コミットされることを防ぎ、master ブランチへマージする前に機能の履歴を整理できる。

Git チュートリアル: git branch

たとえば、リポジトリには小さな機能開発と長期的な機能開発を支える 2 つの独立した開発ラインを持たせることができる。このように開発作業を分岐させることで、両方を同時に進められるだけでなく、基本となる master ブランチを未完成のコードから守ることができる。

ブランチの先端

Git ブランチの背景にある設計思想は、SVN のブランチよりもはるかに軽量である。SVN ではディレクトリ間でファイルを直接コピーするのに対し、Git のブランチはコミットへの参照として保存される。この意味で、ブランチはコミットのコンテナではなく、一連の作業の先端を示すものだといえる。1 つのブランチの履歴は、コミット同士の関係からたどられる。

これは Git のマージモデルに大きな影響を与える。SVN のマージがファイルベースで行われるのに対し、Git はコミットという抽象レベルで作業を行う。実際、プロジェクト履歴のマージは、独立したコミット履歴の結合だと考えられる。

使用例

ブランチを作成する

ブランチは単なるコミットへのポインタであることを理解しておく必要がある。ブランチを作成しても、Git が行うのはポインタの作成だけであり、リポジトリ自体は変更されない。まず、チュートリアル図のような履歴を持つリポジトリがあるとする。

次のコマンドでブランチを作成する。

git branch crazy-experiment

ここではリポジトリの履歴には何の変更も行われない。新しく作られるのは、現在のコミットへのポインタだけである。

Git チュートリアル: 新しいブランチの作成

この操作は単に新しいブランチを作成しただけであることを覚えておこう。このブランチにコミットを追加し始めるには、git checkout でそれを選択し、その後通常どおり git add と git commit を使う。詳しくはこの章の git checkout を参照する。

ブランチを削除する

ブランチでの作業が完了し、master ブランチへのマージも終わっていれば、履歴を失うことなくブランチを削除できる。

git branch -d crazy-experiment

ただし、指定したブランチが完全にマージされていない場合、このコマンドを実行するとエラーが表示される。

error: The branch 'crazy-experiment' is not fully merged.
If you are sure you want to delete it, run 'git branch -D crazy-experiment'.

これにより、コミットへの参照を失うこと、つまり小さなミスによって開発ライン全体へのアクセス手段を失うことを防げる。ブランチを削除してよいと確信している場合、たとえばそのブランチで行った実験的な開発が失敗した場合は、大文字の -D フラグを使う。

git branch -D crazy-experiment

このコマンドを実行すると、ブランチの状態に関係なく警告なしで削除されるため、慎重に使う必要がある。

Git ブランチの種類

Master branch

製品としてリリースできるブランチ。
リリース履歴を管理するために使う。つまり、リリース可能な状態だけを管理する。

Develop branch

次のリリースバージョンを開発するブランチ。
機能開発用ブランチをマージするために使う。すべての機能が追加され、バグが修正され、リリース可能な安定状態になったら、develop ブランチを master ブランチへマージする。
通常はこのブランチを基準に開発を進める。

Feature branch

機能を開発するブランチ。
新機能の開発やバグ修正が必要になるたびに、develop ブランチから分岐する。feature ブランチでの作業は基本的に共有する必要がないため、自分のローカルリポジトリで管理する。
開発が完了したら develop ブランチへマージし、他の人と共有する。

Release branch

今回のリリースバージョンを準備するブランチ。
リリース専用ブランチを使うことで、あるチームがそのリリースを準備している間、別のチームは次のリリースに向けた機能開発を続けられる。つまり、区切られた開発段階を定義するのに適している。
たとえば「今週はバージョン 1.3 のリリースを目標にする」といったことを、チームメンバーと簡単に共有して合意できる。

Hotfix branch

リリース済みバージョンで発生したバグを修正するブランチ。
リリース済みバージョンに緊急修正が必要な場合、master ブランチから分岐する。develop ブランチで問題箇所を修正してリリース可能なバージョンを作るには時間がかかり、安定性の保証も難しいため、すぐにリリース可能な master ブランチから直接ブランチを作り、必要な部分だけを修正して再び master にマージし、リリースする。