A successful Git branching modelを邦訳してちょっとわかりやすくしました！ gitのブランチモデルで悩んでるひととか参考にしてみてください！

1. Git中心の開発ワークフロー

2. 資料概要
• Gitブランチモデル
• モデルに従ったワークフロー
の順番で進めていきます。まず開発モデル
を策定し、それに従ったフロー及びインフ
ラを構築していきたいと思います。

3. Gitブランチモデル

4. １－１ ブランチ一覧
ここでは色を覚え
ておいて下さい。
本番
テスト
開発

5. 1-2 メインブランチ
•
•
Master
Develop
Developは『次期リリースのための最新の開発
作業の変更を常に反映する、最新ソースコー
ド置き場』
developのソースコードが安定しリリース準備
ができたとき、 developの全変更は『masterへ
マージ』され、『リリース番号をタグ付け』す
る
『masterへ変更がマージされる』＝『新しい製
品リリース』
masterにコミットがあるときは毎回Gitのフック
スクリプトで自動ビルドを行い、本番サーバに
ロールアウトする

6. 1-3 サポートブランチ
Master・developのメインブランチの隣で、チームメンバ間の平行開発（下記）
を助ける様々なサポートブランチを用いる。
1. 機能追加 （feature branches 1-3-1）
2. 製品リリースの準備 （release branches 1-3-2）
3. 製品問題をすばやく修正 （Hot-Fix branches 1-3-3）
メインブランチと異なり、サポートブランチは寿命が決まっており、『使い終
わったら削除』される。

7. 1-3-1 feature branches
分岐元： develop
マージ先： develop
ブランチ名の慣習： master, develop, release-*, hotfix-* 以外なら全
てOK
Feature branchesは次期リリースに入る、または遠い将来のリ
リースに入るような『新機能を開発する』のに使われる。
ある機能を開発し始めるとき、その時点ではその機能を含めるべ
きリリースがどれなのか不明である。 feature branchesの本質は、
機能を開発している限りは存在しているが、結局は


developにマージされる（新機能を次のリリースに追加すると決める）
捨てられる（実験が期待はずれの場合）
ということ。
feature branchesは『開発者のリポジトリにだけ存在』し、『オ
リジナルには存在しない』。

8. 1-3-2 realease branches
（その一）
分岐元： develop
マージ先： develop と master
ブランチ名の慣習: release-(リリース日)-*
release branchesは『新しい製品リリースの準備をサポート』す
る。
リリース最後の詰めをしっかりと行うための場所。マイナーバ
グフィクスや、リリースのメタデータ（バージョン番号、ビルド日時、
他）の準備をする。
これら作業をrelease branches上で行うことで、『developは次期
リリースのための機能を受け取るために、キレイな体でいられ
る』。
developから新しいrelease branchesを分岐するタイミングは、
developが新しいリリースの望ましい状態を（ほぼ）反映してい
るとき。
少なくともそのリリースのビルドのターゲットとされる全ての
機能は、この時点で developにマージされていなければならない。
機能開発中のソース（feature branches）のリリースが先になる場
合、release branchesを分岐させるまではdevelopにマージしない
で待つこと。

9. 1-3-2 release branches
（その二）
release branchesを終える
release branchesが本当にリリースされても良い状態になったら、
いくつかの儀式を実行する必要がある。
最初に、 release branchesは masterにマージされる（masterにあるコ
ミットは全て新しいリリースだということ）。
次に、マージコミットにはタグをつけて、後で簡単に見直せる
ようにする。
最後に、 release branchesで行われた変更を developにマージす
る。 releaseでやったバグフィックスなどを将来のリリースに含
めるため。
完全にリリースが終わったら、もう必要が無いのでrelease
branchesを削除する。
まとめ
1.
2.
3.
4.
リリースが決まった時点で、 release branchesを作成
テスト中のバグフィックスは、 release branchesのみに
マージ
リリース後、 release branchesをdevelopにマージ
release branchesを削除する

10. 1-3-3 Hot-Fix branches
（その一）
分岐元： master
マージ先： develop と master
ブランチ名の慣習： hotfix-*
Hot-Fix branchesは、新しい製品リリースへの準備であるという
意味でrelease branchesに似ているが、計画されて行われるわけ
ではない。
それは、現在の製品バージョンの望まざる状態への必要性から発
生する。製品バージョンにあるクリティカルなバグがすぐに解決
されなければならないとき、 Hot-Fix branchesはそのバージョン
のタグがつけられているmaster コミットから分岐されることにな
る。
その本質は、（develop上で）作業しているチームメンバーが作業
を続けられながら、別の人間が製品のすばやい修正を準備できる
ことにある。
masterよりHot-Fix branchesを切り、バージョン番号を増加させる。
それからバグを修正して、コミットを行う。

11. 1-3-3 Hot-Fix branches
（その二）
Hot-Fix branchesを終える
修正が終わった時、そのバグフィックスを次のリリースにもちゃんと含
められるために、 『masterにマージ』されるだけでなく『developにも
マージ』される必要がある。これはrelease branchesを終える時ととて
もよく似ている。
最初に、masterをアップデートして、タグをつける。
次に、バグフィックスをdevelopにも含めさせる。
※ここで一つルールの例外があり、修正タイミングでreleaseが存在して
いたら、『Hot-Fix branchesの修正を developの代わりにreleaseにマー
ジ』しなくていけない。
release branchesにバグフィックスをマージすると、release branches
を終えたときにdevelopにも含まれることになる（developでの作業にこの修正
がすぐに必要で、releaseを終えるのを待てないなら、今ここでも develop にマージする
場合もある）。
最後に、Hot-Fix branchesを削除する。
まとめ
1.
2.
3.
4.
5.
6.
masterからHot-Fix branchesを切る
バージョンを増加させる
バグ修正はHot-Fix branchesのみに反映
Masterをアップデートしてバージョンアップタグ付けする
修正内容をdevelopにも反映
Hot-Fix branchesを削除

12. 参考
A successful Git branching model
• http://nvie.com/posts/a-successful-gitbranching-model/

13. ワークフロー

14. 2-1 ロール
2種類！
スタッフ
リーダー




プロジェクト責任者
ソースレビュー
デプロイ
1プロジェクト1人！
Main / Release / HotFix / Develop
branch




コーディング
ソースアップ要求
テストとか
いっぱいいる
Future branch

15. 2-2 ワークフロー
テスト完了後、
テスト環境に自動デプロイ(Cap)
テス
ト
・継続的インテグレーション
自動監視して、変更があればテスト実行
Develop branch
Git
Capestrano
Jenkins
Pull(Merge)
request
ステージン
グ
Release branch
Hot-Fix branch
Develop
Master branch
Fork
clone
clone
本番
ステージング・本番
は管理者がCapデプロ
イ
リーダーはPull requestを精査し
問題がなければ取り込む
Pull/Push
開発者同士のpull,pushは自由