git-flowのMercurial版hgflow

git-flowのMercurial版hgflowがあると聞いたのでメモ。

【元ネタ】
hgflow - wyukawa’s blog

紹介マニアどらふと版: hgflowを試してみる

yinwm / hgflow / wiki / Home ? Bitbucket

yinwm / hgflow / wiki / UserManual ? Bitbucket

(分散)バージョン管理システムの組織化

subversionでのブランチマネジメント - TIM Labs

git-flow による構成管理とRedmineの関係: プログラマの思索

第3回品川Redmine勉強会の感想 #47redmine: プログラマの思索

【1】hgflowを使うには、yinwm / hgflow / wiki / Home ? Bitbucketからhg clonwして、mercurial.iniへ

[extensions]
hgflow = /PATH/TO/hgflow.py

を追加するだけ。
yinwm / hgflow / wiki / UserManual ? Bitbucketに書いているように、hg flow initから始まり、後はgit-flowのコマンドと同じだ。

【2】(分散)バージョン管理システムの組織化の資料はとても分かりやすい。
メインラインモデルとgit-flowモデルに対し、ブランチ管理の考え方の違いをうまく説明している。

メインラインモデルでは、develop＝trunk。
つまり、メインラインは開発中のコードラインであり、最新の機能がコミット済み。
そして、このtrunkからリリースすればリリースブランチ、特定目的であれば、トピックブランチやタスクブランチが分岐される。
Redmineの開発はメインラインモデルで運用されている。

/ - リポジトリ - Redmine

重要な点は、メインラインはリリース可能なコードラインとは限らないこと。

本来のメインラインの定義は、メインラインの定義: プログラマの思索に書いた通り、「最新の機能を持つ」が「リリース可能」とは限らないが、アジャイル開発を運用しているならば、事実上、メインラインは「リリース可能」なコードラインにならざるを得ないと考えている。

git-flowモデルでは、stable＝trunk。
つまり、メインラインはリリース済みのコードライン又はいつでもリリース可能なコードライン。
開発者は、特定の期日までに開発するマイルストーンブランチをtrunkから派生し、ブランチ上で作業後、trunkへマージする。
masterブランチはtag専用で、リリース時に作られるだけ。

マイルストーンブランチには、序盤の開発と終盤の開発の2種類がある。
序盤は、新機能の開発であるフィーチャブランチが多いだろう。
終盤は、バグ修正のホットフィックスブランチやリリース作業を事前準備するためのリリース準備ブランチが多いだろう。

特に、git-flowないしhgflowを使うならば、ブランチはITSチケット単位に作り、story/#11などのようにチケット番号で分かるようにした方が運用しやすい。

チケット無しでフォークやプルリクエストは許さないというチケット駆動の新しい運用方法: プログラマの思索にも書いたが、チケット単位にブランチ管理する手法は、「No Ticket, No Commit」の拡張版を生み出す可能性を秘めていて、今後の運用で重要な役割を担うと思っている。

但し、第3回品川Redmine勉強会の感想 #47redmine: プログラマの思索にも書いたが、git-flowモデルを採用したChiliprojectはソース管理がとても複雑化しているのに対し、メインラインモデルを採用した本家のRedmineは頻繁なバージョンアップに伴い、どんどん使いやすくなっている。
この辺りの違いについても、次回の品川Redmine勉強会で議論してみたいと思っている。