gitを使用する際、あるブランチをリファクタリングする際、マスターブランチと違いすぎる場合はどうやってマージすればよいでしょうか？

Question

背景: コードがマスター 1.0 バージョンからリファクタリングされ、新しいブランチが v2 と呼ばれるものとします。 再構築プロセス中、マスター 1.0 には新しい変更やバグ修正が常にマージされます。 v2 の開発が完了するまでに、2 つのブランチ間にはあまりにも多くの相違点と競合が存在していました。

このようなシナリオでは、マスター 2.0 をより適切にリリースするにはどうすればよいでしょうか?
実際に、コードをリファクタリングするときに、大量の競合をより適切に回避するにはどうすればよいでしょうか?

Answer 1

こんにちは。合併中のフラッシングに対処する簡単な方法はなく、対応する事業担当者が 1 つずつ対処しなければならない場合があります。
リファクタリングのプロセス中に、マスターはバグに対処し、機能をリリースする必要があるため、いくつかの反対意見があります。 v2 のマージが間に合わないのはなぜですか?
マスター 1 が毎回正式にリリースされると、マスター 2 も時間内にマージでき、競合の量が減ります。

Answer 2

私たちも同様の問題に遭遇しました
たとえば、安定版があり、その下に fs というディレクトリがあります
次に、開発ブランチがあり、その下に fsv2 というディレクトリがあります

。

新しいバージョンは開発時に開発され、fs ディレクトリは廃止されました。関連する fs コードは fsv2 ディレクトリ内で変更されました。

現時点では、ホットフィックスをすぐに実行する必要がある問題が発生しています。ホットフィックスを実装するたびに、この変更を開発の fsv2 ディレクトリにマージするにはどうすればよいですか?新しいブランチの新しいパッチ

これはホットフィックスにも当てはまります。大規模な機能の開発では、安定版は通常必要ありません。統合する前に、共通のディレクトリに置き、より一般的なモジュールにするのが最善です。

これは私自身の経験です、少し遅れているかもしれませんが、アドバイスをお願いします。

Answer 3

一般的に、リファクタリングした部分がマスター1.0で修正されていない場合は、もちろん問題ありません。

リファクタリングされた部分に新たな変更がある場合、2 つのタスクを実行する人々はよくコミュニケーションを取る必要があります。そうしないと、マージ中に間違いなく問題が発生します。

しかし通常、コードの同じ部分を同時にリファクタリングして変更する必要はありません。これを本当に実行したい場合は、2 つのタスクを完全に同期する必要はなく、1 日はリファクタリング、1 日は変更、ブランチのマージを繰り返し行うことができます。