У меня есть специальная ветвь (ветвь релиза), которая является точной копией главной ветки с удаленными файлами и каталогами. На этой ветке не происходит развития, однако она должна быть синхронизирована с мастером, поэтому обновления на главном уровне должны постоянно подталкиваться к этой ветке.
Выполняя нормальное слияние (git merge master), я постоянно получаю конфликты (например, пример файла README):
CONFLICT (delete/modify): README deleted in HEAD and modified in master
который ожидается: я пытаюсь объединить изменения в файлах, которые я удалил. Поэтому, чтобы разрешить их, я использую git rm README.
Чтобы автоматизировать его, я мог бы использовать автоматическое разрешение конфликтов, указав -X ours. Человеческие страницы говорят, что для меня это правильно:
This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree that do not conflict with our side are reflected to the
merge result.
Однако, когда я делаю git merge -s recursive -X ours master, я все равно получаю одинаковые нерешенные конфликты удаления/изменения. Что я делаю не так? Есть ли другой способ автоматизировать разрешение конфликтов?
Вероятно, лучший способ сделать это, но я решил аналогичную проблему, выполнив слияние (со стратегией слияния по умолчанию), а затем запустив
git status --porcelain | awk '{if ($1=="DU") print $2}' | xargs git rm
После этого вы должны разрешить другие конфликты как обычно, а затем зафиксировать.
Это просто удаляет все файлы, которые были удалены в текущей ветке, и я думаю, это то, что вы хотите.
git merge master
git status --porcelain | awk '{if ($1=="DU") print $2}' | xargs git rm
git commit
Рассмотрев этот вопрос, похоже, что рекурсивная стратегия с нашими или их опцией не рассматривает удаление как конфликт.
Что вы можете сделать, это использовать эту функцию, чтобы указать конкретную стратегию для некоторых файлов. Я бы поспорил, что наша стратегия (не опция) будет делать трюк для этих файлов.
EDIT:
Как указано в комментарии, вы не можете этого сделать!
Вы должны обязательно связаться с Git списком рассылки, если это очень важная функция для вас (git @vger.kernel.org)
Вы можете использовать rebase вместо merge для активации ветки release.