Mercurial を使用してワークフローを処理するための適切な方法を見つけるのに苦労しています。ここSOや他の場所で関連する多くの質問を読みましたが、合理的な解決策が見つかりませんでした。
2 つのブランチがあるとします。
- 通常の開発を行うデフォルトのブランチ。リリースをデプロイし、リリース タグでマークする
- 個別に維持される特定の顧客のブランチ。古いバージョンのアプリケーションから分岐した別のバージョン番号で実行されます。
これら 2 つのブランチは現在ほとんど同じですが、すでにいくつかの違いがあります。時間が経つにつれて、それらはさらに離れていきます。
これは、4 種類のソース ファイルがあることを意味します。
- タイプ A : 両方のブランチで同一のままのファイル (変更が導入された場合、両方に存在する必要があります)。これらはほとんどのファイルです。
- Type-B : default ブランチのみにあり、customer ブランチにマージする必要がないファイル
- Type-C : customer ブランチのみにあり、default ブランチにマージする必要がないファイル
- Type-D : 両方のブランチに存在し、コードを共有しているが、各ブランチに固有の分離したままにする必要があるコードも含むファイル
開発はデフォルト ブランチで行われ、ほとんどがインクリメンタルな定期リリースがあります。しかし、次の 2 つのシナリオもあります。
- デフォルト ブランチに加えられたいくつかの変更は、カスタマー ブランチにもマージする必要があります (例: 両方に修正/追加する必要があるバグまたは機能)。
- 顧客ブランチに対して行われた「ホットフィックス」であり、すぐにデフォルト ブランチにマージすることはできませんが、いずれかの時点で最終的にマージする必要があります。
問題は、これら 2 つのシナリオをサポートするための合理的にシンプルでクリーンで安全な方法を見つけられないことです。Mercurial には、部分的なマージやマージ時にファイルを無視するという概念がありません。変更セットをマージしますが、以前のリビジョンで導入されたファイルを含めることを主張します。
これらのシナリオで default を customer ブランチに、または customer を default にマージすると、Type-B および Type-C のファイルを追加する必要があります。他のブランチに追加する必要のない Type-A のファイルに変更を加える (Type-D にする) と、課題が発生します。
明らかに、これらの問題のいくつかは、コンパイラ定義を使用して (したがって、両方のブランチでソース ファイルを同じに保つ)、コードを手動で編集し、マージ後にファイルを手動で削除することで回避できますが、これは最も効率的でクリーンな処理方法とは思えません。これ。
確かに、これは私よりも賢い人がすでに理解した、十分に一般的なワークフローです。これらのシナリオで作業を合理化できる方法またはベスト プラクティスを提案できる人はいますか? または、私のセットアップに根本的な欠陥がありますか?
また、Git はこれらのフローをより適切に処理しますか?
ありがとう。