Archiwa tagu: rebase

A więc do tego służy git rebase!

Miałam zakończyć raportowanie postępów w nauce systemu kontroli wersji Git, ale właśnie zrozumiałam coś istotnego.

Lubię często wysyłać stan pracy do repozytorium – czuję się wtedy bezpiecznie (chociaż akurat Eclipse jest dość pomocny jeśli chodzi o odzyskiwanie wersji z lokalnej historii). Podczas pracy nad poprzednim wpisem wysłałam do swojego lokalnego repozytorium Git masę głupich “testowych” commitów. Byłam przekonana, że nie zostawią śladu w ostatecznej wersji w GitHub. Tyle że… zostawiły! Przy wypychaniu zmian do repozytorium zdalnego przekazywana jest tam cała historia. O wstydzie, o chaosie!

Podczas dzisiejszych eksperymentów z silnikiem szablonów Thymeleaf, nauczona doświadczeniem oraz komentarzami do wcześniejszego wpisu, postanowiłam skorzystać z opcji git rebase -i, która pozwala interaktywnie uporządkować i scalić commity. W ten sposób do zdalnego repozytorium w serwisie GitHub trafi ostateczny i kontrolowany wynik mojej pracy, a nie poszczególne jej fragmenty.

A było tak:

1. Potrzebowałam trzech commitów, żeby przy użyciu Thymeleaf zwrócić użytkownikowi powitalną stronę:

Aktualny stan aplikacji (commit bbafde0)
Aktualny stan aplikacji (commit bbafde0)

2. Eclipse jak zwykle trzymał rękę na pulsie:

O trzy kroki do przodu względem zdalnej gałęzi master
O trzy kroki do przodu względem zdalnej gałęzi master

3. Nie potrafię użyć interaktywnego rebase w Eclipse, dlatego na chwilę przenoszę się do konsoli:

4. Konsola gita usłużenie wyświetla mi plik w edytorze vim, który to edytor zawsze jest mile widziany pod Windowsem (not):

Co mogę zrobić z moimi trzema commitami?
Co mogę zrobić z moimi trzema commitami?

Edycja pliku pociągnie za zmianę historii repozytorium. Na samej górze widać moje trzy commity i towarzyszące im opisy. Poniżej mam bardzo czytelną instrukcję. Słowo pick na początku każdej z trzech linii odpowiadających commitom mogę zamienić na jedną z dostępnych komend.

5. Oto mój wybór:

Zdecyduj się, człowieku!
Zdecyduj się, człowieku!

Zdecydowałam, że chcę wcielić dwa ostatnie commity do pierwszego i odrzucić ich opisy (fixup), a także zmienić opis pierwszego commita (reword).

6. Po zamknięciu i zapisaniu pliku pojawia się kolejny, w którym mogę edytować opis jedynego pozostałego przy życiu commita:

Nowy komentarz do commita
Nowy komentarz do commita

7. Wracam do konsoli, gdzie czeka na mnie podnoszący na duchu komunikat:

8. Wracam do Eclipse. Po odświeżeniu projektu widzę, że rzeczywiście commity w lokalnym repozytorium zostały scalone do jednego:

Tylko jeden krok do przodu względem zdalnej gałęzi master
Tylko jeden krok do przodu względem zdalnej gałęzi master

9. Wypycham kod do GitHuba. Tym razem na stronie widać jeden kompletny commit, a nie zbieraninę drobnicy, jak poprzednio.

Jeden commit zamiast trzech
Jeden commit zamiast trzech

PS. Zrozumiałam już, że mimo że jestem tu sama, nie powinnam pracować w gałęzi master. Mam natomiast wątpliwości związane z wypychaniem chwilowych branchy do GitHuba. Może wypowie się któryś z moich gitowych pomocników?

PS2. To jest czwarty wpis na temat Gita. Poprzednie to: