UWAGA: Ta odpowiedź zmienia SHA1, więc uważaj, aby użyć jej na gałęzi, która została już wypchnięta. Jeśli chcesz tylko poprawić pisownię nazwy lub zaktualizować stary e-mail, git pozwala to zrobić bez przepisywania historii przy użyciu .mailmap
. Zobacz moją drugą odpowiedź .
Korzystanie z Interactive Rebase
Mógłbyś
git rebase -i -p <some HEAD before all of your bad commits>
Następnie zaznacz wszystkie swoje złe zmiany jako „edytuj” w pliku bazy danych. Jeśli chcesz również zmienić swoje pierwsze zatwierdzenie, musisz ręcznie dodać je jako pierwszą linię w pliku rebase (postępuj zgodnie z formatem pozostałych linii). Następnie, gdy git poprosi cię o zmianę każdego zatwierdzenia, zrób to
git commit --amend --author "New Author Name <email@address.com>"
edytuj lub po prostu zamknij edytor, który się otworzy, a następnie zrób
git rebase --continue
aby kontynuować rebase.
Możesz pominąć otwarcie edytora tutaj, dodając, --no-edit
aby polecenie było:
git commit --amend --author "New Author Name <email@address.com>" --no-edit && \
git rebase --continue
Single Commit
Jak zauważyli niektórzy komentatorzy, jeśli chcesz tylko zmienić ostatnie zatwierdzenie, polecenie rebase nie jest konieczne. Po prostu zrób
git commit --amend --author "New Author Name <email@address.com>"
Spowoduje to zmianę autora na podaną nazwę, ale podmiot ustawiający zostanie ustawiony na skonfigurowanego użytkownika w git config user.name
i git config user.email
. Jeśli chcesz ustawić moduł ustalający na określony przez siebie element, spowoduje to ustawienie zarówno autora, jak i modułu zmieniającego:
git -c user.name="New Author Name" -c user.email=email@address.com commit --amend --reset-author
Uwaga dotycząca zatwierdzeń scalania
W mojej pierwotnej odpowiedzi była niewielka wada. Jeśli są jakieś zatwierdzenia scalania między bieżącym HEAD
a twoim <some HEAD before all your bad commits>
, wówczas git rebase
je spłaszczysz (a przy okazji, jeśli użyjesz żądań ściągania GitHub, w twojej historii będzie mnóstwo zatwierdzeń scalania). Może to często prowadzić do bardzo odmiennej historii (ponieważ duplikaty zmian mogą zostać „wycofane”), aw najgorszym przypadku mogą prowadzić do git rebase
prośby o rozwiązanie trudnych konfliktów scalania (które prawdopodobnie zostały już rozwiązane w zatwierdzeniach scalania). Rozwiązaniem jest użycie -p
flagi do git rebase
, która zachowa strukturę scalania twojej historii. Strona podręcznika dla git rebase
ostrzega, że używanie -p
i -i
może prowadzić do problemów, ale wBUGS
w sekcji napisano: „Edytowanie zatwierdzeń i przeredagowanie ich komunikatów zatwierdzeń powinno działać dobrze”.
Dodałem -p
do powyższego polecenia. W przypadku, gdy zmieniasz tylko najnowsze zatwierdzenie, nie stanowi to problemu.