0

私はSVNを使用する開発チームで働いています。常に安定したリリース可能なトランクを維持します。すべての開発はブランチで行われ、リリースの準備ができたらトランクにマージされます。トランクにマージする前に何かを表示/テストする必要がある場合は、そのブランチ(機能ブランチと呼ばれることもあります)を開発環境にデプロイして、他の開発者やプロジェクトマネージャーがそれを見ることができます。これはほとんどの場合うまく機能します。それがうまく機能しないのは、同じリリースサイクルの一部であるが、必ずしも相互に関連しているとは限らない複数の異なるブランチがある場合です。これらはすべて、同じ期間にトランクにマージする前に承認する必要があります。 。私たちが考えていたのは、それらすべてを結合されたリリースブランチにマージすることです。問題は、マージされたブランチの一部のみがリリースを承認された場合、トランクに移動する前に、それらのブランチなしでマージをやり直す必要があるということです。基本的に、マージを2回実行する必要があります。1回は開発ブランチまたは機能ブランチに、次に2回目は、承認されたリリース可能なブランチをトランクにマージします。

これを行うためのより良い方法はありますか?個々のブランチから機能ブランチにマージした後、後でそれらの個々のブランチをトランクにマージすると、問題が発生する可能性があるように感じます。私はそれを考えるのは正しいですか、それともこれは問題ではありませんか?

4

2 に答える 2

1

Aphillippe の提案に従って、さらに一歩進んで、トランクからリリース ブランチを作成し、個々のパッチ リリースごとにタグ付けすることができます。

このアプローチにより、ライブの不具合をトランクから切り離してリリース ブランチで修正できます (これらの修正はトランクにマージする必要があります)。分離により、クライアントはソフトウェアの最新バージョンにアップグレードすることなく、欠陥修正を取得できます。これにより、「完全な」アップグレードに関連する潜在的にかなりのテスト時間を節約できます。

于 2012-04-12T08:41:32.243 に答える
0

これがタグの目的ではないでしょうか。

個々の機能に取り組みながら分岐します。テストのために、それらをすべてトランクにマージします。テストが完了し、バグが修正され、リリースの準備が整ったら、トランクにタグを付けます。次に、リリースごとにタグを付けます。

トランクにリリース可能なコードのみを含める必要があることをよく理解していません。確かに、トランクにリリース不可能なコードを決して入れないことはほとんど不可能です (二重否定を許すなら)。

于 2012-04-12T08:26:39.643 に答える