git-flowのmasterブランチにあたるものはリリースタグで十分ではないかという仮説を持っています
- リリースする際は、developからリリースブランチを生やし、そこでQAや修正コミット追加をしてOKとなったらリリースタグを打つ。
リリースタグをの付いたコミットが本番リリースなりパッケージ公開なりされる
- リリースタグを打った時点でリリースブランチはdevelopへ戻しマージする
- リリース済みバージョンの緊急修正が必要になった場合は最新のリリースタグからhotfixブランチを生やしてそこで修正やQAを行い、OKとなったらリリースタグを打つ。同じくdevelopへ戻しマージする
これでgit-flowでやりたかったことは十分できているのではないかと。
あえてmasterブランチを持つ理由があるとしたら
- 最新のリリースがどれだかわかりやすいようにするマーカー
- リリースブランチやhotfixブランチをWebツール上でマージリクエストの形にできるのでQA工程が可視化できる
というのも考えられますが、前者は「タグリストの一番大きい数字を見ろ」で十分に感じますし、後者もdevelopへのマージリクエストにできるのでとなります。
むしろmasterという直接コミットしてはいけない先がコミット可能ポインタであるブランチであるよりはコミット不能ポインタであるタグである方が用途と機能があっているのではと思っておりの質問です。
どう考えるのが良いでしょうか。
回答1件
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2019/12/26 07:31
2019/12/26 08:46
2019/12/26 08:55
2019/12/27 04:10
2019/12/27 04:23