過去
Subversion を scm として使用してソフトウェア プロジェクトを開発しています。これまで開発は常に で行われてtrunkいたため、バグ修正リリースが必要になると問題が発生しました。ここで、分岐戦略を再考したいと考えています。要件は次のとおりです。一度に複数の将来のリリースに取り組めるようにしたいのです。
タスク
つまり、現在取り組んでいるバージョンが 1.0 であるとします。次に予定されているバージョンは 2.0、その次のバージョンは 3.0 です。1.0 をリリースしたので、
- バージョン 1.0 を維持する
- 2.0 の機能を開発する
- 同時に 3.0 の機能を開発する
もちろん、1.0 で適用された修正は、他の 2 つのバージョンでも必要です。さらに、2.0 の機能も 3.0 に含める必要があります。また、マイナー リリースが計画されている可能性もあります。たとえば、1.1 には新機能も含まれており、個別に維持する必要があります。
可能な解決策
次の分岐戦略を思いつきました。
- トランクは捨てます
- 新しく計画されたリリースごとに、最後のリリース ブランチに由来するブランチが作成されます。
- 変更は、バージョン タイムラインで「上方」に反映されます
これをもう少し詳しく説明しましょう。この例では、トランクからバージョン 1.0 を分岐します。また、バージョン 1.0 からバージョン 2.0 を分岐し、バージョン 2.0 からバージョン 3.0 を分岐します。1.0 で変更が行われると、2.0 にマージされ、その後 3.0 にマージされます。
質問
これは有効な方法論ですか？技術的にうまくいくでしょうか？組織の落とし穴はありますか？ベストプラクティスはありますか? （インターネットで思いつくのは、「トランクで開発し、リリースブランチで維持する」だけです）。トランクを放棄するのは特に奇妙に思えます-それは間違っていますか?