7

Vincent Driessenによって提案された分岐モデルを採用し、彼の記事で説明されているようにほぼすべてのことを行います。

リリース ブランチの処理に関してのみ、少し逸脱します。

Vincent は、開発者から分岐したブランチで機能を開発することを提案しています。次のリリースに含まれる機能が決定されると、それらは開発者にマージされ、そこからリリース ブランチが作成されます。

その後、機能ブランチはテストとバグ修正にのみ使用する必要があります。リリースがライブにデプロイされると、リリース ブランチは開発者とマスターにマージされます。

代わりに、機能をリリース ブランチに直接マージします。 ブランチ モデリングのリリース

私はこれが行われるべき方法ではないと感じており、これが実際に物事をより複雑にする可能性があるケースを考えようとしています.

私が考えることができる1つは次のとおりです。

新しい機能 cが、既にリリース ブランチにマージされている機能 a の上に構築されているとします。開発者から新しい機能 cブランチを作成できるようにするには、最初にリリース ブランチを開発者にマージする必要があります。

この分岐モデルが物事をより複雑にする可能性がある他のケースはありますか?

4

1 に答える 1

8

私が考えることができる1つのケースは、これが事態を複雑にする可能性がある場合、それがさらなる開発を妨げ始めることです.

次のリリースですぐに使用できる機能 A を開発しているとします。現在、機能 A に大きく依存している機能 B に取り組んでいる別の開発チームがありますが、数回のスプリント後にのみリリースする必要があります。したがって、明らかに、機能 A から機能 B を分岐させます。

今、機能 A にバグが見つかりました。機能 A のリリースが近づいています。ホット フィックス/ハックまたは適切なコードのリファクタリングと修正の 2 つのオプションがあります。

時間の制約があるため、ホットフィックスを用意するのが賢明ですが、将来を考えると、適切なリファクタリングと修正が必要です。

幸いなことに、私たちは両方に行くことができます.

あなたの戦略（私が理解していることから）では、リリースブランチはすべてのパッチとホットフィックス（5つ以上のコミットを含む）を受け取ります。これは、機能Aにそのようなものをコミットできないためです（ポリシーに厳密な場合）。一度に 10 個以上の機能がある場合、そのような修正リリースの数を考慮してください。

しかし、Vincent Driessen の戦略では、機能とリリースの間の隠し場所として開発ブランチが常に存在するため、そのようなホット フィックスについては、開発ブランチにマージしてから、ホット フィックスのためにそこから分岐し、開発ブランチにマージしてから、リリース。また、機能ブランチのどこにもハック/ホットフィックスがないという利点があります。機能に基づくさらなる機能は、並行して継続できます。また、ホットフィックス ブランチを破棄するか、履歴から削除することができます。これは唯一の視点であり、おそらくこの場合、あなたの戦略を守ることができます. 私は私の答えでさらなる議論と修正を受け入れています:)

そして、これは私が伝えていることを描いたかなり厄介な画像です. Git 分岐図

于 2013-07-15T20:37:59.873 に答える