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ę:
2. Eclipse jak zwykle trzymał rękę na pulsie:
3. Nie potrafię użyć interaktywnego rebase w Eclipse, dlatego na chwilę przenoszę się do konsoli:
|
1 |
$ git rebase -i |
4. Konsola gita usłużenie wyświetla mi plik w edytorze vim, który to edytor zawsze jest mile widziany pod Windowsem (not):
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:
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:
7. Wracam do konsoli, gdzie czeka na mnie podnoszący na duchu komunikat:
|
1 2 3 4 5 6 7 8 9 10 11 |
$ git rebase -i [detached HEAD a89b890] thymeleaf template added with static resources and a controller 1 file changed, 10 insertions(+) create mode 100644 src/main/resources/templates/greeting.html [detached HEAD bbafde0] thymeleaf template added with static resources and a controller 5 files changed, 61 insertions(+), 14 deletions(-) create mode 100644 src/main/java/pl/namiekko/hello/GreetingController.java create mode 100644 src/main/resources/static/img/szafa.jpg create mode 100644 src/main/resources/static/main.css create mode 100644 src/main/resources/templates/greeting.html Successfully rebased and updated refs/heads/master. |
8. Wracam do Eclipse. Po odświeżeniu projektu widzę, że rzeczywiście commity w lokalnym repozytorium zostały scalone do jednego:
9. Wypycham kod do GitHuba. Tym razem na stronie widać jeden kompletny commit, a nie zbieraninę drobnicy, jak poprzednio.
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:
- No i Git! Kontrola wersji służy nie tylko programistom
- Git w Eclipse
- Git: przedzieram się przez gałęzie
Bardzo przydatne są Twoje na temat Gita 🙂 Może zmobilizuję się do porządkowania swoich commitów i scalania ich w coś większego
Bardzo mi miło to przeczytać. Tym bardziej, że na Facebooku trollują mnie, że mam przeczytać książkę o Gicie i przestać się ekscytować 🙂
Którą? Pro Git?
Tak sądzę 🙂 A dzisiaj ktoś mi zwrócił uwagę, że jest też wersja polska.
O, nie wiedziałem.
To bardzo dobra książka. Tyle, że po jej przeczytaniu można zacząć się ekscytować jeszcze bardziej, widząc, jakie rzeczy można zrobić w Gicie.
No i a propos rebase’owania i w ogóle Gita – jedno słowo: Magit. (Zobacz np. https://www.youtube.com/watch?v=vQO7F2Q9DwA .) Używam go od dłuższego czasu i nie sądzę, żeby dało się zrobić lepszy frontend do Gita. Niemal codziennie np. stage’uję i commituję nawet nie tylko pojedyncze hunki, ale wybrane linie kodu, i jest to bardzo, bardzo wygodne. (Android Studio, jak się zdaje, nie potrafi zastage’ować nawet na poziomie hunków – a przynajmniej nie za bardzo widać, jak to zrobić. Nie wiem, jak jest w Eclipse.)
Jak lubisz często commitować w ramach pracy nad jakąś logiczną całością możesz amendować commity (git commit –amend) : wtedy git „doklei” aktualnie zmiany do poprzedniego commita. Jest to trochę wygodniejsze niż robienie rebase’a na końcu pracy, ale to już jak wolisz.
Polecam https://gitextensions.github.io
To bardzo fajne GUI i wolę z niego korzystać niż z tych wbudowanych do eclipse czy idea. Ma to tą zaletę że można łatwo otworzyć podgląd na np. kilka repozytoriów bez specjalnego obciążenia kompa.