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

Ответ 1

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

git rebase -i -p HEAD~5

Ответ 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 " git rebase -p сообщения журнала фиксации слияния, которая теперь исправлена.

См. Комм. Ed5144d (08 февраля 2018) Грегори Эрреро ('').
Предложено: Вегардом Носсумом (vegard) и Квентином Касасновасом (casasnovas).
^{(Объединено Junio C Hamano - gitster - в коммите 8b49408, 27 февраля 2018 г.)}

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

Поскольку commit dd6fb00 (" rebase -p: исправить 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."

после rebase -p.

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

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

Ответ 3

Еще один приятный ответ, используя только примитивные команды - knittl fooobar.com/questions/58215/...:

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, используя примитивные команды, может иметь приятную "особенность" не потреблять слишком много CPU и заставлять вас ждать неизвестного времени, пока Git не закончит думать о списке коммитов, нуждающихся в переустановке в случае git rebase -p -i HEAD^^^^ (такая команда, которая привела бы к списку из 4 последних коммитов с объединением, поскольку последний в моем случае в моем случае занял около 50 секунд!).

Ответ 4

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

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

Ответ 5

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