成功したGitブランチモデル：なぜ私はマスターとしてリリースブランチを使用すべきではありませんか？

Question

これは愚かな質問かもしれませんが、なぜ自分のリリースブランチをマスターとして使用できないのか分かりません。私は "成功したGitブランチモデル"（http://nvie.com/posts/a-successful-git-branching-model/）のアイデアが気に入っていますが、リリースブランチをマスターにマージすると、多くの競合を解決する必要があることがわかります。なぜ私のマスターとしてリリースブランチを使用しないのですか？

ありがとうございます！

EDIT 申し訳ありません申し訳ありませんが私は十分な質問を明確にしませんでした。私が言っていたことは、このGitブランチモデルと、リリースブランチから新しいブランチへのチェックアウトの違いは何か、それを私の新しいマスターブランチとして使用することでした。リリースブランチを元のマスターにマージし、新しいマスターブランチをチェックアウトすることに違いがありますか？

Answer 1

「あなたのリリースブランチをmasterとしてどのように使用しますか？本当に何を意味するのかは分かりません。 masterの内容と使用方法を見て、リリースブランチでこれらのことを実行できるかどうかを確認してください。

まず、masterにマージするとコードの新しい状態を作成してはいけません（これはあなたの反対であると思われる）。あなたはそれが何もしないと思うかもしれない。しかしそれはそうします：それはこの特定のバージョンが実際のリリースであることを伝えます。それは生産に展開され、クライアントに出荷されています。リリースブランチの先端である古いバージョンは、本番環境では使用できない可能性があります。もちろん、それを回避するために何らかのタグ付け規約を使用することもできますが、あまり優雅ではないソリューションがあると思います。

次に、私がmasterをチェックアウトした場合、変更されていない単一の名前 - 私は最新のプロダクションリリースバージョンがあることを知っておく必要があります。私がリリースブランチだけに頼っているのであれば、私が望むバージョンが何であるか知っていなければなりません。自動展開ツールにはそれほど便利ではないかもしれません。動くタグを使うこともできますが、それは反パターンのようなものです。タグはちょうどrefです。移動するrefが必要な場合は、その解決策があります：分岐。そしてそれはmasterです。私はmasterにいる時

、私は

git log --first-parent 

のようなものを行うことができますし、彼らが起こった順に示すリリース（そして、ついでに、またホットフィックス）で、リリース履歴を参照してください。スクリプティングの歪みがなく、誰かが大会を壊したために何か不具合が発生する（または表示されない）というリスクはありません。

を使用し、特別な名前の長寿命ブランチを持つ理由の一部は、コミットトポロジには、現在のコードバージョンまで追加されたパッチのコレクションを超えるドキュメンタリ値があります。