Zmień stary komunikat dotyczący zmiany w Git

Próbowałem edytować stary komunikat dotyczący zmiany, jak wyjaśniono tutaj .

Chodzi o to, że teraz, kiedy próbuję uruchomić rebase -i HEAD~5, mówi interactive rebase already started.

Więc próbuję: git rebase --continueale mam ten błąd:

error: Ref refs/heads/master is at 7c1645b447a8ea86ee143dd08400710c419b945b but expected c7577b53d05c91026b9906b6d29c1cf44117d6ba
fatal: Cannot lock the ref 'refs/heads/master'.

Jakieś pomysły?

To mówi:

Kiedy zapiszesz i wyjdziesz z edytora, przewinie cię on z powrotem do ostatniego zatwierdzenia na tej liście i upuści cię w wierszu poleceń z następującym komunikatem:

$ git rebase -i HEAD~3
Stopped at 7482e0d... updated the gemspec to hopefully work better
You can amend the commit now, with

To nie znaczy:

Wpisz ponownie git rebase -i HEAD~3

Staraj się nie pisać git rebase -i HEAD~3przy wychodzeniu z edytora i powinno działać dobrze.
(w przeciwnym razie w twojej konkretnej sytuacji git rebase -i --abortmoże być potrzebny, aby zresetować wszystko i pozwolić ci spróbować ponownie)

Jak wspomina Dave Vogt w komentarzach, git rebase --continuechodzi o przejście do następnego zadania w procesie zmiany bazy, po poprawieniu pierwszego zatwierdzenia .

Ponadto, Gregg Lind wspomina w swej odpowiedzi rewordpoleceń zgit rebase :

Zastępując polecenie „wybierz” poleceniem „edytuj”, możesz nakazać git rebasezatrzymanie po zastosowaniu tego zatwierdzenia, aby móc edytować pliki i / lub komunikat o zatwierdzeniu, zmienić zatwierdzenie i kontynuować zmianę bazy.

Jeśli chcesz po prostu edytować komunikat o zatwierdzeniu dla zatwierdzenia, zamień polecenie „ pick” na polecenie „ reword” od Git1.6.6 (styczeń 2010) .

Robi to samo ' edit' podczas interaktywnego ponownego bazowania, z wyjątkiem tego , że pozwala tylko edytować komunikat zatwierdzenia bez zwracania kontroli do powłoki . Jest to niezwykle przydatne.
Obecnie, jeśli chcesz wyczyścić swoje wiadomości w zmianach, musisz:

$ git rebase -i next

Następnie ustaw wszystkie zatwierdzenia na „edytuj”. Następnie na każdym:

# Change the message in your editor.
$ git commit --amend
$ git rebase --continue

Użycie „ reword” zamiast „ edit” pozwala pominąć wywołania git-commitigit-rebase .

Jak zasugerował Gregg Lind, możesz użyć polecenia reword, aby otrzymać monit, aby zmienić tylko komunikat o zatwierdzeniu (i pozostawić zatwierdzenie nienaruszone w przeciwnym razie):

git rebase -i HEAD~n

Oto nlista ostatnich n zatwierdzeń.

Na przykład, jeśli używasz git rebase -i HEAD~4, możesz zobaczyć coś takiego:

pick e459d80 Do xyz
pick 0459045 Do something
pick 90fdeab Do something else
pick facecaf Do abc

Teraz zastąpi wydłubać z przeredagować dla zatwierdzeń chcesz edytować wiadomości z:

pick e459d80 Do xyz
reword 0459045 Do something
reword 90fdeab Do something else
pick facecaf Do abc

Wyjdź z edytora po zapisaniu pliku, a następnie zostaniesz poproszony o edycję komunikatów dla zatwierdzeń, które zaznaczyłeś jako przeredagowanie , w jednym pliku na wiadomość. Zauważ, że to byłoby znacznie prostsze wystarczy zmienić popełnienia wiadomości, kiedy otrzymuje picksię reword, ale robi to nie ma znaczenia.

Dowiedz się więcej na stronie GitHub dotyczącej zmiany komunikatu o zmianach .

FWIW, git rebase Interactive ma teraz opcję „przeredagowania”, co sprawia, że ​​jest to znacznie mniej bolesne!

Chciałem tylko zapewnić inną opcję do tego. W moim przypadku zwykle pracuję nad swoimi indywidualnymi oddziałami, a następnie łączę się w master, a indywidualne commity, które wykonuję w moim lokalnym, nie są tak ważne.

Ze względu na hak git, który sprawdza odpowiedni numer biletu w Jira, ale rozróżnia wielkość liter, uniemożliwiono mi wypchnięcie kodu. Ponadto zatwierdzenie zostało wykonane dawno temu i nie chciałem liczyć, ile zatwierdzeń wróci do rebase.

Więc to, co zrobiłem, to utworzenie nowej gałęzi z najnowszego mastera i zmiażdżenie wszystkich zatwierdzeń z gałęzi problemowej do jednego zatwierdzenia w nowej gałęzi. Było mi łatwiej i myślę, że warto mieć to tutaj jako odniesienie w przyszłości.

Od ostatniego mistrza:

git checkout -b new-branch

Następnie

git merge --squash problem-branch
git commit -m "new message" 

Referencja: https://github.com/rotati/wiki/wiki/Git:-Combine-all-messy-commits-into-one-commit-before-merging-to-Master-branch

Oto bardzo ładne streszczenie, które obejmuje wszystkie możliwe przypadki: https://gist.github.com/nepsilon/156387acf9e1e72d48fa35c4fabef0b4

Przegląd:

git rebase -i HEAD~X
# X is the number of commits to go back
# Move to the line of your commit, change pick into edit,
# then change your commit message:
git commit --amend
# Finish the rebase with:
git rebase --continue