ブランチとは
作業履歴を枝分かれさせて記録していくためのもの。
使うと何がいいのか？
- 他のブランチの影響を受けないため複数の作業を同時に進められる
- 作業単位で履歴を残すことで後で見た時にわかりやすい
つまり、複数人で開発するときにはそれぞれが他の作業者の影響を受けずに進められるし、ひとりで開発する場合でも作業履歴を綺麗に管理しておけるので使用した方がいい。
ブランチの運用
統合ブランチ
リリース版がいつでも作成可能なようにしておくためのブランチ。
なので、常に安定した状態を保っておくことが重要。
通常、masterブランチを統合ブランチとする。
トピックブランチ
機能追加やバグ修正といったある課題に関する作業を行うためのブランチ。
安定した統合ブランチから分岐する形で作成し、作業が完了したら統合ブランチに取り込むという使い方をする。
ブランチの切り替え
ブランチを切り替えるにはチェックアウトという操作を行う。
チェックアウトすると移動先の最終コミット内容にバージョンが変わる。
まだコミットしていない内容があるのにチェックアウトした場合
変更内容がチェックアウトしたブランチに移動する。
競合する場合はチェックアウトに失敗する。
そのような場合はスタッシュをして変更内容を退避させてからチェックアウトする。
ブランチの統合
ブランチの統合にはマージとリベースの2つがある。
マージ
マージは統合ブランチにチェックアウトしている状態で、トピックブランチをマージするという手順で行う。
トピックブランチが統合ブランチから分岐した状態から統合ブランチが編集されていなければ普通にマージされるだけで完了する。これを早送りマージという。
もし、統合ブランチが編集されていればそれぞれを統合した新たなコミットが統合ブランチで行われる。
リベース
リベース元の履歴がリベース先のブランチの後ろに追加される形で一本化される。
マージとリベースは例えば下記のように使い分ける
- トピックブランチに統合ブランチの最新のコードを取り込む場合はrebaseを使う
- 統合ブランチにトピックブランチを取り込む場合は、まずrebaseしてからmerge
ブランチの名前づけ
master
- リリース可能な状態だけを管理する
- 特定のブランチからマージすることによってしか更新されない
- 直接コミットしてはならないという制約をもつ
- バージョンごとのtagはここから生まれる
develop/[バージョン番号など]
- 先のリリースに向けた普段の開発で使用する
- 後述のfeatureやreleaseブランチはここから派生
feature/[派生元バージョン番号など]/[機能名など]
- 機能追加・改修などを行う作業ブランチ
- developブランチから、featureブランチを切る
- 完了後はdevelopブランチにマージされて、featureブランチは削除される
その他
- release/[バージョン番号]
- fix/[バージョン番号]/[バグ識別名]
- support/[バージョン番号]
- hotfix/[バージョン番号]/[バグ識別名] or hotfix/[バグ識別名]