Git: Jak edytować / przeformułować wiadomość merge commit?

Jak edytować lub przeformułować komunikat zatwierdzenia scalającego?

git commit --amenddziała, jeśli jest to ostatnie dokonane zatwierdzenie ( HEAD), ale co, jeśli nastąpi wcześniej HEAD?

git rebase -i HEAD~5 nie wymienia zatwierdzeń scalania.

Jeśli dodasz --preserve-mergesopcję (lub jej synonim, -p) do git rebase -ipolecenia, git spróbuje zachować scalenia podczas ponownego bazowania, zamiast linearyzować historię, i powinieneś być w stanie zmienić również zatwierdzenia scalania:

git rebase -i -p HEAD~5

Zwróć uwagę, że uruchomienie git1.7.9.6 (i git1.7.10 +) git mergesamo zawsze wywoła edytor , abyś mógł dodać szczegóły do ​​scalenia.

„ git merge $tag” aby scalić oznaczony tagiem, zawsze otwiera edytor podczas interaktywnej sesji edycji. Seria v1.7.10 wprowadziła zmienną środowiskową GIT_MERGE_AUTOEDIT, aby pomóc starszym skryptom w odrzuceniu tego zachowania, ale ścieżka konserwacji również powinna ją obsługiwać.

Wprowadza również zmienną środowiskową, GIT_MERGE_AUTOEDITaby pomóc starszym skryptom w odrzuceniu tego zachowania.

Zobacz „ Przewidywanie Git 1.7.10 ”:

Niedawno w dyskusji na liście dyskusyjnej Git Linus przyznał (i zgodziłem się), że był to jeden z błędów projektowych, które popełniliśmy na początku historii Gita.
W wersji 1.7.10 i nowszych, polecenie git merge, które jest uruchamiane w sesji interaktywnej (tj. Zarówno jego standardowe wejście, jak i standardowe wyjście podłączone do terminala) otworzy edytor przed utworzeniem zatwierdzenia, aby zapisać wynik scalania, aby dać użytkownik ma szansę wyjaśnić scalanie, tak jak robi to polecenie git commit, które użytkownik wykonuje po rozwiązaniu konfliktu scalającego.

Linus powiedział:

Ale tak naprawdę nie obchodzi mnie, jak to naprawdę działa - moim głównym problemem jest to, że git sprawia, że ​​zbyt łatwo jest mieć złe komunikaty o scalaniu.
Myślę, że część tego jest jeszcze prostszym idiotyzmem: nigdy nawet domyślnie nie uruchamiamy edytora dla „git merge”, ale robimy to dla „ git commit”.
To był błąd projektowy, a to oznacza, że ​​jeśli chcesz faktycznie dodać notatkę do scalenia, musisz wykonać dodatkową pracę. Więc ludzie tego nie robią .

Zauważ, że przed Git 2.17 (Q2 2018), " git rebase -p" zniekształcone komunikaty dziennika dotyczące zatwierdzenia scalania, które teraz zostało naprawione.

Zobacz commit ed5144d (08 lutego 2018) autorstwa Gregory Herrero (``) .
Sugerowane przez: Vegard Nossum ( vegard) i Quentin Casasnovas ( casasnovas) .
^{(Scalone przez Junio ​​C Hamano - gitster- w zatwierdzeniu 8b49408 , 27 lutego 2018 r.)}

rebase -p: napraw niepoprawny komunikat o zatwierdzeniu podczas wywoływania git merge.

Od momentu zatwierdzenia dd6fb00 (" rebase -p: fix quoting when calling git merge", styczeń 2018, Git 2.16.0-rc2), komunikat zatwierdzenia zatwierdzenia scalającego, którego podstawa jest zmieniana, jest przekazywany do polecenia merge za pomocą wykonywania podpowłoki ' git rev-parse --sq-quote'.

Potrzebne są podwójne cudzysłowy wokół tej podpowłoki, aby dla git mergepolecenia zostały zachowane znaki nowej linii .

Przed tą poprawką następująca wiadomość dotycząca scalania:

"Merge mybranch into mynewbranch

Awesome commit."

staje się:

"Merge mybranch into mynewbranch Awesome commit."

po a rebase -p.

W Git 2.23 (Q2 2019), merge -cinstrukcja " " podczas " git rebase --rebase-merges" powinna dać użytkownikowi szansę na edycję komunikatu dziennika, nawet jeśli w innym przypadku nie ma potrzeby tworzenia nowego scalania i zastępowania istniejącego (tj. Zamiast tego przewiń do przodu ), ale tak się nie stało.
Który został poprawiony.

Zobacz commit 6df8df0 (02 maja 2019) autorstwa Phillip Wood ( phillipwood) .
^{(Scalone przez Junio ​​C Hamano - gitster- w zobowiązaniu c510261 , 13 czerwca 2019 r.)}

Kolejna fajna odpowiedź przy użyciu tylko prymitywnych poleceń - przez knittl https://stackoverflow.com/a/7599522/94687 :

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

lub lepsza (bardziej poprawna) ostateczna komenda rebase:

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

Przy okazji, używanie prymitywnych poleceń może mieć tę fajną "cechę" polegającą na tym, że nie zużywa zbyt dużo procesora i sprawi, że będziesz czekać nieznany czas, aż Git skończy myśleć o liście zatwierdzeń, które należy zmienić w przypadku git rebase -p -i HEAD^^^^(takie polecenie, które spowodowałoby lista tylko 4 ostatnich zatwierdzeń z scaleniem jako ostatnia w moim przypadku w moim przypadku zajęła około 50 sekund!).

git merge --edit
Umożliwia udzielenie komentarza nawet w przypadku nieinteraktywnego scalania.

git merge --edit --no-ff może być przydatne, jeśli podążasz za przepływem git z ponownym bazowaniem na gałęzi programistycznej i scalaniem z nią bez szybkiego przewijania do przodu.

Aktualne wersje Git (maj 2020):

git rebase -i -r <parent>,

następnie zastąpić w edytorze merge -C ...z merge -c ....

Spowoduje to otwarcie komunikatu o zatwierdzeniu w edytorze podczas ponownego bazowania, gdzie można go zmienić.

(Dzięki VonC za podpowiedź .)

git rebase -i HEAD~5Poleceń wyskakuje edytor. Zawiera listę określonych zatwierdzeń (w tym przypadku pięciu z nich). Pierwsza kolumna zawiera pickdla każdego zatwierdzenia. Wystarczy wymienić pickze rewordw tym edytorze i zapisz + zamknij edytor. Wtedy będzie git pop-up edytor dla każdego popełnić gdzie zmienił picksię rewordi pozwoli na edycję commit wiadomość.