Обычный термин для этого: union merge ; см. ссылку в комментарии grg . Не существует стратегии -s и опции -X eXtended-option для любой из существующих стратегий, чтобы сделать объединение файлов низкоуровневым слиянием. Однако вы можете создать файл .gitattributes и указать там merge=union, а у команды git merge-file есть опция --union, а также опции --ours и --theirs.
(Предположительно, никто не выдвинул -X union в качестве расширенного аргумента к существующей стратегии рекурсивного решения / разрешения, потому что так редко требуется это.)
Обсуждение стратегий слияния
* 1020 Стратегия * octopus очень особенная: она реализует относительно простое слияние, которое позволяет вам объединить более одного коммита с текущим (HEAD) коммитом. Требуется, чтобы это слияние имело никаких конфликтов в любом месте , поскольку в нем нет места для записи всех временных входов. Стратегии resol и recursive обрабатывают конфликты слияния путем копирования трех входных файлов - базы слияния, --ours и --theirs - в индекс в трех слотах индекса и затем используя существующий git merge-file код 1 для объединения этих трех файлов, записывая маркеры конфликта в окончательную выходную версию.
Обратите внимание, что стратегия -s resolve, реализованная git merge-resolve команда, такая же, как git merge-recursive (и реализуется тем же базовым кодом), с одним исключением: если git merge-recursive находит две или более фиксации базы слияния, git merge -s resolve просто выбирает один из них случайным образом, тогда как git merge-recursive сначала объединяет базы слияния для создания нового коммита, а затем использует новый коммит в качестве базы слияния.
Стратегия -s subtree является рекурсивной стратегией; по ходу дела он просто переименовывает файлы.
Оставшаяся стратегия (-s ours) даже не вычисляет базу слияния, поскольку фактически не выполняет слияние.
По сути, тогда На самом деле существует только две стратегии слияния : рекурсивная и осьминог. Остальные стратегии - это всего лишь модификации рекурсивных или вовсе не операций слияния (-s ours).
Вы можете написать свою собственную стратегию слияния. Просто напишите любую команду на любом исходном языке и назовите исполняемый двоичный файл git-merge-foo или git-merge-xyzzy или любой другой. Запуск git merge -s foo или git merge -s xyzzy теперь будет вызывать вашу стратегию с недокументированными аргументами, которые вы должны разгадать. Эти аргументы должны определять ваш выбор базы слияния и процесс слияния. Все оставлено на ваш собственный код, включая, как определить и реализовать слияние, и как git add получить файлы в индексе, и как запустить git commit (если вы собираетесь запустить его вообще). Чтобы сделать будущую запись фиксации фактическим слиянием, ваша команда должна оставить правильные файлы bread-crumb-trail в каталоге Git (git rev-parse --git-dir) на основе текущего рабочего дерева (начиная с Git 2.5).
1 Буквально не запускается git merge-file: вместо этого базовый код для выполнения слияний находится в различных исходных файлах, и оба git merge-file и git merge-recursive вызывают один и тот же Базовый код. Этот код принимает три входа и записывает один вывод. Для git merge-recursive три входа сохраняются в индексе; для git merge-file три хранятся в трех файлах файловой системы. Выходными данными во всех случаях является копия файла рабочего дерева. Если слияние завершается без конфликтов, git merge-recursive перемещает этот файл в нулевой интервал подготовки и продолжается без конфликтов, но git merge-file просто завершается с нулевым статусом. Если это объединение вызывает конфликты или не удается по другим причинам, git merge-recursive оставляет беспорядок в индексе и рабочем дереве и переходит к следующему файлу, как обычно, тогда как git merge-file просто завершается с ненулевым статусом.