git merge: есть ли способ работать с задействованными файлами, даже если нет конфликта слияния?

Question

Конфликт слияния возникает тогда и только тогда, когда две ветви имеют модификацию одной и той же строки перед слиянием.Однако, даже если конфликт слияния не произойдет, возможно, что результат слияния двух прекрасно работающих ветвей не сработает.Есть способ предварительно объединить две ветви, работая с файлами, которые должны появиться в результате объединения (возможно, также добавить / удалить / изменить другие), а затем зафиксировать результат объединения?Я пытался, но у меня есть такая возможность, только когда происходит конфликт слияния и только в строке кода.Я уверен, что это можно сделать в git (я не могу быть единственным с этой проблемой), но я не знаю последовательность команд для запуска.

Answer 1

Вы также можете сначала выполнить слияние, затем протестировать его, исправить проблемы и, наконец, git commit --amend свои исправления в коммите слияния, прежде чем нажать его.

Answer 2

(Это должен быть комментарий, но он немного длинный и требует некоторого форматирования.)

В то время я пишу два ответа:

• git merge --no-commitскорректируйте результаты (и git add при необходимости) и подтвердите, используя git commit или git merge --continue;или
• git merge, проверьте и исправьте (и git add при необходимости) и используйте git commit --amend, чтобы убрать старый коммит слияния с пути, заменив его новым и улучшенным.

Оба будут работать.Тем не менее, обратите внимание, что существует школа мысли, в которой говорится, что вы никогда не должны делать ни одного из них, поскольку невозможно будет использовать автоматизированную систему для повторения слияния в будущем.Мне не ясно, какой вариант предпочитают те, кто подписывается под этим правилом, так как их два:

• Перед слиянием сделайте коммит (или несколько коммитов), который подготовит все, чтобы автоматическое слияние завершилось успешно, ивыдаст действительный результат.
• Или, после того, как автоматическое объединение завершится успешно, но выдаст недопустимый результат, сделайте последующий коммит, который исправит его.

В любом случае, любая "prepare"или "исправить" коммиты, и любые коммиты, которые не работают сами по себе , должны, вероятно, иметь пояснительное лог-сообщение.Если само слияние не работает, обратите внимание, что в сообщении журнала коммита слияния: замените довольно бессмысленное сообщение merge branch <name> на что-то вроде:

automatic but broken merge of branch <name>

This merge has the contents that Git produces on its own,
and exists so that someone who is repeating the work in the
future can do it automatically as well, and compare.  The
*next* commit contains the manual change that makes the
merge functional, so when bisecting, use the *next* commit,
not this one.

Конечно, если вы предпочитаете школуМысль, которая гласит: «Не делайте преднамеренно нарушенных коммитов», вы просто объедините и исправите (либо с --no-commit, либо с --amend, в зависимости от того, что вы предпочитаете).

Answer 3

git merge --no-commit <branchName>

предназначен именно для этой цели (см. документ ).

(впоследствии вам не нужно делать git merge --continue, просто зафиксируйте свою работу, когда текущее состояниев соответствии с вашими потребностями. Не забывая add любую модификацию, которую вы могли бы ввести после вашего необязательного слияния)