Más contenido relacionado
La actualidad más candente (20)
Similar a Gitを使った開発ワークフロー (20)
Gitを使った開発ワークフロー
- 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/