W przypadku historii zmian w systemie kontroli wersji bardzo istotny jest dobry ich opis. Bez niego może pojawić się problem z szybkim dojściem to tego, co dana zmiana w kodzie miała oznaczać. Poza tym wszelkie narzędzia zarządzania projektami (Jira, Redmine itp.) często integrują się z odpowiednio zredagowanymi komunikatami, a literówki są dość częstymi błędami, które dotyczą nawet programistów.

W sytuacji w której szybko orientujemy się, że popełniliśmy błąd, z pomocą przychodzi wtedy najprostsze z możliwych rozwiązań pozwalające na zmianę opisu ostatniej zmiany:

git commit --amend

Niestety czasami bywa i tak, że o błędzie (lub błędach) orientujemy się po kilku kolejnych zatwierdzeniach. Wybawieniem bywa wtedy komenda rebase w trybie interaktywnym:

git rebase --interactive a0781e73041ad38bc4b16ac9c33b38fc2ff61cad

Powyższe polecenie wyświetla w edytorze tekstowym dotychczasową historię i pozwala nam na wybranie odpowiednich zatwierdzeń do zmiany. Pozostawienie przed daną pozycją polecenia pick (lub samej litery p) pozostawia ją bez zmian. W przypadku chęci zmiany komunikatu, wystarczy użyć komendy reword (lub samej litery r). Po zapisaniu zmian i zamknięciu edytora, zostaniemy poproszeni w kolejnych krokach o ewentualną zmianę wybranych opisów (tyle razy, ile zatwierdzeń wybraliśmy).

Na koniec wystarczy zweryfikować przepisaną historię:

git log

Należy pamiętać, że w przypadku zmiany opisów zatwierdzeń obowiązują zasady analogiczne, co przy zmianie historii. Oznacza to tyle, że wypchnięcie zmian na serwer zakończy się niepowodzeniem, jeśli nie wymusimy tego w sposób siłowy:

git push --force

Przy okazji jest to dość jasny sygnał, że rozwiązanie to powinno być stosowane w ostateczności i bardzo ostrożnie (szczególnie na gałęzi głównej).