リリース、開発、機能、およびバグ修正ブランチで動作する git ワークフロー モデルに関する次の優れたブログ投稿に出くわしました: http://nvie.com/posts/a-successful-git-branching-model/
これは素晴らしいワークフローのように思えます。実際に本番環境で試してみたいと思っていますが、ある段落が私の注意を引き、不思議に思っています。
次のリリースにバージョン番号が割り当てられるのは、リリース ブランチの開始時であり、それ以前ではありません。それまでは開発ブランチに「次のリリース」の変更が反映されていましたが、その「次のリリース」が最終的に 0.3 になるか 1.0 になるかは、リリース ブランチが開始されるまで不明です。その決定は、リリース ブランチの開始時に行われ、バージョン番号バンピングに関するプロジェクトのルールによって実行されます。
この作業方法は、チケット発行およびバグ追跡システムにどのように反映されるのでしょうか? JIRA と BugZilla では、チケットが所属できる「バージョン」を作成します。リリース ブランチに切り替える前に、開発ブランチにある場合、チケットはどのバージョンに属しますか? すべてのブランチのイシュートラッカーにバージョンがありますか?
また、今後のリリースではなく、その後のリリースで実装することがわかっている機能チケットについてはどうでしょうか? この種のチケットの「今後」と「将来」のバージョンを作成する必要がありますか?
この分岐ワークフローがチケット/問題管理にどのように反映されるかについての洞察をいただければ幸いです。