Jeszcze parę lat temu, gdyby ktoś mi powiedział, że mam zrobić jakikolwiek rebase, to uciekłabym daleko. Wszelkie akcje w GitBashu napawały mnie przerażeniem. Tylko jedna komenda była dla mnie w miarę bezpieczna:

git status

Czemu? Ponieważ nie mogła niczego popsuć. Pokazywała tylko listę wprowadzonych zmian na aktualnym branchu.

Jednak wraz z upływem czasu GitBash stał się moim przyjacielem. Pomimo prób zaprzyjaźnienia się z graficznymi interfejsami gita np. SourceTree, surowa otoczka konsoli bardziej do mnie przemawiała 😀

Dlatego dzisiaj pokażę jedną z moich ulubionych komend, czyli, jak zrobić rebase interaktywny.

Częste commity

O tym, że powinno się robić dużo commitów, wie chyba każdy. Dzięki temu wrzucamy co jakiś czas zakończone fragmenty kodu. Jeśli coś popsujemy – wystarczy cofnąć ostatni commit. Zerknijmy więc na przykładowe małe commity, które mogliśmy zrobić pracując nad jakąś funkcjonalnością:

• commit #1 – dodatnie property Confirmed do modelu

• commit #2 – dodanie sprawdzenia, czy obiekt User nie jest nullem

• commit #3 – dodanie property GenderType do modelu

• commit #4 – aktualizacja mappera

Oddanie kodu do review

Po zakończeniu prac nad taskiem zapewne chcemy wysłać kod do review. Co zobaczy osoba odpowiedzialna za review w historii zmian?

Prywatnie takie niewielkie zmiany związane z jedną funkcjonalnością wolałabym mieć poukładane w jednym commicie.  Dzięki temu widziałabym od razu część funkcjonalności i mogłabym zaakceptować bądź odrzucić commit jako jedną całość.

Jak więc teraz złączyć te 4 commity w jeden? Wystarczy jedna komenda!

Widzimy, że nasz branch wywodzi się z mastera:

Chcemy dodać więc 1 commit, który powstał po commicie o id 3a069f. Włączamy więc GitBash i wpisujemy komendę:

git rebase -i 3a069f

• Etap 1 – wybór commitów

Opcja squash

Zostaje nam wyświetlona lista commitów, które zostały utworzone po wpisanym jako parametr commicie. Na liście widzimy więc nasze 4 commity. Mamy również napisaną instrukcję, co możemy z nimi zrobić. Załóżmy, że do pierwszego commita chcemy dokleić (opcja squash) pozostałe. Wystarczy więc dla tych commitów ustawić opcję squash (lub skrót s).

Opcja fixup

Dodatkowo możemy zauważyć, że 3. commit ma bardzo podobny opis do opisu commita nr 1. Warto więc użyć opcji fixup (lub skrótu f), żeby automatycznie pominąć jego opis w kolejnym kroku.

Po uzupełnieniu konsola powinna wyglądać tak:

VIM – ŚCIĄGA

1. Naciśnij klawisz „i” w celu przejścia do trybu wprowadzania
2. Wpisz konkretne wartości
3. Naciśnij klawisz „Esc”, żeby wyjść z trybu wprowadzania
4. Zapisz plik i wyjdź wpisując komendę wq (write i  quit)

• Etap 2 – wybór opisu commita

W tym kroku mamy wypisane wszystkie opisy wcześniejszych commitów. Należy teraz wybrać i zaktualizować te, które chcemy wykorzystać. Zauważ, że opis commita #3 jest już zakomentowany – stało się tak dzięki użyciu parametru fixup (w skrócie f) w poprzednim kroku.

Po uzupełnieniu opisy mogą wyglądać następująco:

Po zapisaniu zmian (jeśli potrzebujesz, skorzystaj jeszcze raz z VIM – ŚCIĄGA) rebase jest zakończony:

Nadpisywanie historii

Należy pamiętać o tym, że nadpisaliśmy historię zmian (na razie tylko lokalnie). Gdy zechcemy wysłać nasze zmiany na serwer, wystarczy wpisać komendę:

git push

Co teraz zobaczymy w historii?

Mamy 1 commit ze zmianami w 3 plikach – dokładnie to, co chcieliśmy zrobić.

PS1 – oczywiście wiele graficznych programów typu SourceTree czy Tortoise udostępnia opcję robienia interaktywnych rebase, więc nie trzeba tego robić w konsoli 🙂

PS2 – do zwizualizowania zmian użyłam programu Fork.

PS3 – jeśli zwykład komenda push nie zadziała, to znaczy, że trzeba użyć parametru force (w skrócie f). Używanie tej komendy na prywatnym branchu jest jak najbardziej w porządku. Jednak nie powinno się jej używać na ważnych gałęziach typu master. W niektórych projektach zdarza się nawet, że ta komenda jest zablokowana – nie wszyscy mogą więc zmieniać historię.