Git: Как редактировать / перефразировать сообщение коммита слияния?

Question

Как мне отредактировать или переформулировать сообщение коммита слияния?

git commit --amend работает, если это последний сделанный коммит (HEAD), но что, если он наступит раньше HEAD?

git rebase -i HEAD~5 не перечисляет коммиты слияния.

Answer 1

Если вы добавите параметр --preserve-merges (или его синоним -p) к команде git rebase -i, то git попытается сохранить слияния при перебазировании, а не линеаризовать историю, и вы сможете изменитьтакже происходит слияние:

git rebase -i -p HEAD~5

Answer 2

Обратите внимание, что начиная с git1.7.9.6 (и git1.7.10 +), git merge сам по себе всегда будет вызывать редактор , чтобы вы добавили детали к объединению.

"git merge $tag" для объединения аннотированного тега всегда открывает редактор во время сеанса интерактивного редактирования.Серия v1.7.10 представила переменную среды GIT_MERGE_AUTOEDIT, чтобы помочь старым сценариям отклонить это поведение, но дорожка обслуживания также должна его поддерживать.

Также вводится переменная среды GIT_MERGE_AUTOEDITчтобы помочь старым сценариям отклонить это поведение.

См. " Предвидение Git 1.7.10 ":

Недавно в обсудив список рассылки Git , Линус признал (и я согласился), что это была одна из ошибок проектирования, которые мы допустили в начале истории Git.
А в 1.7.10 и более поздних команда git merge, котораязапускается в интерактивном сеансе (т. е. как его стандартный ввод, так и его стандартный вывод, подключенный к терминалу) откроет редактор перед созданием коммита для записи результата слияния, чтобы дать пользователю возможность объяснить слияние, как gitКоманда commit, которую пользователь запускает после разрешения конфликтующего слияния, уже делает.

Линус сказал:

Но я не совсемглубоко волнуюсь, как это на самом деле работает - моя главная проблема в том, что git слишком облегчает получение плохих сообщений слияния.
Я думаю, что отчасти это еще более простой идиотизм: по умолчанию мы даже не запускаем редактордля "git merge", но мы делаем для "git commit".
Это было ошибкой проекта, и это означает, что если вы действительно хотите добавить заметку к слиянию, вам придется проделать дополнительную работу.Поэтому люди не .

---

Обратите внимание, что до Git 2.17 (Q2 2018) "git rebase -p" искажало сообщения журнала коммита слияния, который теперь исправлен.

См. коммит ed5144d (08 февраля 2018 г.) Грегори Эрреро (``) .
Предложено: Vegard Nossum (vegard)) и Квентин Касасновас (casasnovas) .
^{(Объединено с Junio ​​C Hamano - gitster - в commit8b49408 , 27 февраля 2018 г.)}

rebase -p: исправить некорректное сообщение о фиксации при вызове git merge.

, начиная с commit dd6fb00 ("rebase -p: исправить кавычки при вызове git merge", январь 2018 г., Git 2.16.0-rc2), сообщение о коммите перебазируемого коммита слияния передается команде слияния с использованием подоболочки, выполняющей 'git rev-parse --sq-quote'.

Двойные кавычки необходимы вокруг этой подоболочки, так что для команды git merge сохраняются новые строки.

Перед этим патчем следующее сообщение о слиянии:

"Merge mybranch into mynewbranch

Awesome commit."

становится:

"Merge mybranch into mynewbranch Awesome commit."

послеa rebase -p.

---

С Git 2.23 (Q2 2019), инструкция "merge -c" при "git rebase --rebase-merges"должен дать пользователю возможность редактировать сообщение журнала, даже если в противном случае нет необходимости создавать новое слияние и заменять существующее (т. е. выполнять быструю перемотку вперед), но это не так.
Что было исправлено.

См. коммит 6df8df0 (02 мая 2019 г.) Филиппа Вуда (phillipwood) .
^{(Объединено Junio ​​C Hamano -- gitster - в коммит c510261 , 13 июня 2019 г.)}

Answer 3

Еще один приятный ответ с использованием только примитивных команд - от knittl https://stackoverflow.com/a/7599522/94687:

git checkout <sha of merge>
git commit --amend # edit message
git rebase HEAD previous_branch

или лучшей (более правильной) финальной команды rebase:

git rebase <sha of merge> previous_branch --onto HEAD

BTW, используяПримитивные команды могут иметь приятную «особенность», заключающуюся в том, что они не потребляют слишком много ресурсов ЦП и заставляют вас ждать неизвестное время, пока Git не закончит думать о списке коммитов, которые необходимо перебазировать в случае git rebase -p -i HEAD^^^^ (такая команда, которая приведет ксписок только 4 последних коммитов со слиянием, так как последний в моем случае в моем случае занял около 50 секунд!).

Answer 4

git merge --edit
Позволяет вам комментировать даже в случае неинтерактивного слияния.

git merge --edit --no-ff может быть полезно, если вы следите за потоком git, перебазируя ветку разработки и сливаясь с ней.без быстрой перемотки вперед.

Answer 5

Команда git rebase -i HEAD~5 открывает редактор. В нем перечислены указанные коммиты (в данном случае пять из них). Первый столбец содержит pick для каждого коммита. Просто замените pick на reword в этом редакторе и сохраните + закройте редактор. Затем git будет открывать редактор для каждого коммита, где вы изменили pick на reword, и позволит вам редактировать сообщение коммита.