Git: Як відредагувати / переробити повідомлення комісії про злиття?

Як відредагувати або переробити повідомлення комісії про злиття?

git commit --amendпрацює, якщо це остання фіксація ( HEAD), але що робити, якщо вона виникає раніше HEAD?

git rebase -i HEAD~5 не вказує на об'єднання комітетів.

Якщо ви додасте в команду --preserve-mergesопцію (або її синонім, -p), git rebase -iто git намагатиметься зберегти злиття під час перезавантаження, а не лінеаризувати історію, і ви також зможете внести зміни до комісій злиття:

git rebase -i -p HEAD~5

Зауважте, що, починаючи 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) та Quentin Casasnovas ( casasnovas) .
^{(Об’єднано Хуніо С Хамано - gitster- у комітеті 8b49408 , 27 лютого 2018 р.)}

rebase -p: виправити неправильне повідомлення про фіксацію під час дзвінка git merge.

Оскільки присвоєння 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."

після а rebase -p.

З Git 2.23 (Q2 2019), " merge -c" інструкція під час " git rebase --rebase-merges" повинна дати користувачеві можливість редагувати повідомлення журналу, навіть коли в іншому випадку немає необхідності створювати нове злиття та замінювати існуюче (тобто замість швидкого перемотування вперед) ), але не зробив.
Що було виправлено.

Див. Комісію 6df8df0 (02 травня 2019 р.) Від Phillip Wood ( phillipwood) .
^{(Об'єднав Хуніо С Хамано - gitster- у комітеті c510261 , 13 червня 2019 р.)}

Ще одна приємна відповідь, використовуючи лише примітивні команди - від knittl https://stackoverflow.com/a/7599522/94687 :

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

або краща (більш правильна) остаточна команда ребазування:

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

BTW, використовуючи примітивні команди, може мати гарну "особливість" не витрачати занадто багато процесора і змусити вас чекати невідомий час, поки Git закінчить думати про список комітетів, які потребують перебазування у випадку git rebase -p -i HEAD^^^^(така команда, що призведе до перелік лише 4 останніх з’єднань із об'єднанням як останній у моєму випадку у моєму випадку зайняв близько 50 секунд!).

git merge --edit
Дозволяє коментувати навіть у разі неінтерактивного злиття.

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

Для поточних версій Git (Май 2020):

git rebase -i -r <parent>,

потім замініть в редакторі merge -C ...на merge -c ....

Це відкриє повідомлення про фіксацію в редакторі під час перезавантаження, де ви можете його змінити.

(Дякую VonC за підказку .)

git rebase -i HEAD~5Команда з'являється редактор. У ньому перераховані зазначені коміти (в даному випадку їх п'ять). Перший стовпець містить pickкожну комісію. Просто замініть pickз rewordцього редакторі і зберегти + закрийте редактор. Тоді мерзотник з'явиться редактор для кожної фіксації , де ви змінили , pickщоб rewordі дозволить вам відредагувати повідомлення фіксації.