私はこれをテストしていませんが、これはあなたが望むことをするかもしれません:
git checkout master
git merge -s recursive -X theirs branch-c
git merge -s recursive -X theirs branch-a
git merge -s recursive -X theirs branch-b
これはrecursive
マージ戦略を使用していますが、マージ時に競合がある場合は、現在のブランチにマージしているブランチを優先して常に競合を解決するように言っています。このためのドキュメントを見つけるには、git mergeのマニュアルページにある再帰的マージ戦略のセクションと、その戦略のours
およびtheirs
オプションを参照してください。
これに伴う問題は、各ブランチのファイルに加えた変更が競合しない場合、一方のブランチともう一方のブランチからの変更の一部が発生することです。それがあなたの望むものではない場合(そして私はそもそもあなたのワークフローを完全に理解していないことを認めます)、あなたは例えば:
git merge --no-commit branch-c
...次に、マージコミットをコミットする前に、必要な各ファイルバージョンでインデックスを手動で更新します。そのコマンドを実行した後、次のように両方のブランチに存在するすべてのファイルを見つけることができます。
comm -1 -2 <(git ls-tree -r --name-only master|sort) <(git ls-tree -r --name-only branch-c|sort) > common.txt
...次にbranch-c
、それぞれのバージョンを次のように選択します。
xargs -n 1 git checkout branch-c -- < common.txt
...そしてgit commit
いつものようにコミットします。
繰り返しになりますが、私はこれを絶対にやりたくないと確信しています-gitのデフォルトのマージ動作は、ほとんどの場合、私が望むことを実行し、解決するために本物の競合を残すだけです。