一部のファイルでのみマージ競合を解決し、他のチームで解決するためにブランチにコミットします

Question

要するに、機能チーム別のサーバーチーム、モバイルチーム、ciチーム、自動化チームなどのコードをホストする1つのレポがあります。

サポートブランチのバグ修正から開発者ブランチへのダウンを試みると、さまざまなチーム/開発分野に関連する多くの競合が発生します。サーバーサイドとモバイルをカバーする独身の人はいないので、1人の紛争を解決するのは本当に難しい作業です。

ここで問題となるのは、いくつかの競合（たとえばサーバー側）のみを解決し、中間ブランチにプッシュし、他のチームに自分の開発領域に関する競合を解決させることができるかどうかです。そして、すべてのチームが全ての競合を解決した後でさえ、最終的に中間ブランチをマージします。

多分私たちはここで何か間違っています。どんな提案も（コードベースを別のレポに分割することを除いて、このため遅すぎる）評価されるだろう。

Answer 1

git checkout -b server-team-merge dev-release-branch 
git merge support-team-fixes 
# fix the conflicts you can fix here 
git commit -m "server-team partial merge of $(git describe support-team-fixes)" 

と同様にします。それは、一度に1でそれらをマージ文句場合

git checkout dev-release-branch 
git merge {server,mobile,ci,automation}-team-merge 

、結果は本当にばらばらだった場合は、一度にすべてを行うことができ、それは些細な操作になるだろうけど - 次に、部分的マージのブランチをマージどのような紛争解決が必要かについて、さまざまなアイデアを出す。

ブランチをマージすると、gitはその結果を、結果のコミットのマージされた履歴の正しいマージとしてみなします。その後のマージは履歴全体を共有として識別し、何も残されません。しかし、あなたが同じ親から複数の独立したマージを行う場合、それらのマージはお互いの歴史にはなく、あなたが望む結果を得ることができます。これらの結果のその後のマージで、Gitはコミットの祖先を見て正しいベースを特定することができます。

Answer 2

さて、あなたはこのような何かしてみてください可能性があります

1. チェックアウトdev-release-branchをしてsupport-branchで最初のマージを開始します。
2. できるだけ多くの競合を解決します（1人で）。その男がマージできなかったファイルとディレクトリは、dev-release-branchの状態に戻す必要があります。
3. 結果の状態をa-half-of-a-mergeとして確定し、（一時的なローカル）タグとして保存します。その前のマージ状態
4. から
5. 戻すdev-release-branchは、ソースツリーの他の部分をマージすることができます別の男によってsupport-branchでanothermergeを実行します。繰り返しますが、手順2のように考慮しないように変更してください。
6. 変更があった場合は、手順3〜5を繰り返します（確かに別のタグ名を選択してください）。

最後の「ドメイン」からのすべての競合が解決されたが、マージコミットがまだ作成されていない場合は、異なる「ハーフタグ」からの変更の結合を開始しましょう。

1. 現在の変更セットをインデックスに追加します。
2. cherry-pickは、最初のhalf-tagから変更されています。 -mスイッチ（おそらく-m 1）と--no-commit
3. のマージペアレントを指定する必要があります。うまくいけば、リストは
4. 短いかは自明であろう指標
5. 繰り返しに変更を加えるすべてのhalf-tags
6. が最終的に偉大なマージをコミットするために2-4を繰り返します。
7. すべてのハーフタグを安全に削除できます。

あなたが気づいたことがあるように、プロセス全体はやや長く、複雑で面倒です。将来のリリースでは、プロジェクトを適切な数のサブプロジェクトに分割し、git submodulesを使用して大きなプロジェクトに結合することをお勧めします。