System kontroli wersji GIT to potężne i momentami skomplikowane narzędzie. Pod maską kryje się wiele mechanizmów czy taktyk o których większość Użytkowników nigdy się nie dowie, bo… wcale nie musi. Dzięki temu łatwo nauczyć się GITa do poziomu „wystarczającego” i przy normalnej pracy używać, przez 95% czasu, dosłownie czterech prostych poleceń.
Możesz znać takie komendy jak git init czy git clone których użyjesz kilka razy w roku, bo w końcu w ilu projektach będziesz pracować? Z kolei git revert lub git reset i tym podobne – jeśli nie mieszasz ostro w kodzie i robisz wszystko z głową (ok, po prostu według sprawdzonych „procedur”), użyjesz ich… raz czy dwa. Rocznie. Jeśli w ogóle.
Jak wygląda praca
Zakładam że pracujesz „hybrydowo”. Nad kodem pracujesz w IDE, repozytorium obsługujesz przez CLI a na szersze zmiany patrzysz w odpowiedniej aplikacji webowej. Oddzielasz poszczególne aspekty swojej pracy pomiędzy narzędzia. Osobiście uważam że to wygodne i bezpieczne.
Wygodne, bo piszemy kod w naszym ulubionym IDE, które obecnie płynnie integrują się z repozytorium gita. Dzięki temu na liście plików widzimy które są zmodyfikowane lub czy mają konflikty. W oknie edytora (pliku) widzimy które linie się zmieniły, możemy podglądać kto i kiedy je zmienił (IDE skorzysta z git blame) jak również obsługiwać konflikty. IDE odczytuje metadane z repozytorium, ładnie formatuje i uwalnia nas od przechodzenia do konsoli z każdą pierdołą. To pozwala na skupienie się nad kodem a nie klikaniem po okienkach.
Wygodne, bo czytamy zawartość commitów w przeglądarce, przeprowadzając code review z innymi deweloperami czy tworząc pull/merge requesty. To pozwala na przestawienie myślenia z pisania na czytanie i współpracę z zespołem.
Bezpieczne, bo zapisujemy zmiany do repozytorium i wysyłamy je na serwer przy pomocy minimalistycznego, a przez to bardzo przejrzystego terminala (wiem, można polemizować). Nie musimy klikać, po prostu analizujemy trochę suchych informacji i podejmujemy szybkie decyzje – dodaj, zapisz, zaktualizuj, wyślij. Nie piszemy kodu, zapisujemy.
Używaj GIT w CLI
Wspominałem że tych komend jest tylko 4, i nie są one skomplikowane. Te „skomplikowane” do czytania zawartości repo świetnie ogarniają IDE i tego im nie zabierajmy. W konsoli skupmy się nad zapisywaniem, bo to jest najważniejsze. To na tym etapie można popełnić „głupie” błędy, namieszać a potem musieć cofać zmiany.
Cofanie zmian przez revertowanie czy twarde resetowanie to niesamowicie przydatne narzędzia w wielu sytuacjach, jednak lokalnie – to mało eleganckie. No i zabiera masę czasu, bo teraz będziemy dłuuugo analizować co cofnąć. Łatwiej na bieżąco sprawdzać co robimy. Lepiej też nie „przeklikiwać się” przez GITa wewnątrz IDE. Szczerze polecam używać GITa w konsoli, a nie w już i tak przeładowanym informacjami IDE gdzie łatwiej o miss-click lub wybranie znajomo brzmiącej opcji, która jednak zadziałała nieco inaczej.
Unikaj bałaganu stosując 3 proste zasady:
- Składaj zmiany po każdej konkretnej funkcjonalności lub poprawce,
- Zanim zrobisz
git commit, sprawdź dwa razy co właściwie zapisujesz, - Często pobieraj zmiany z serwera (
git pull) i rozwiązuj konflikty na bieżąco;
Ok, przejdźmy wreszcie do tych siedmiu czterech wspaniałych.
Popularne komendy GIT
Stosując się do tych 3 zasad znacząco uprościmy sobie pracę z GITem. Edytując w „jednej partii” tylko pliki konkretnej funkcjonalności, zwykle będzie ich dość mało, więc git status będzie łatwy do odbioru. Nie zmieniamy plików nie związanych z czymś innym, więc do zakomitowania możemy użyć polecenia git commit -am "<opis>" który wykona git add . za nas, zamiast zastanawiać się które pliki teraz edytowaliśmy a które mamy tylko „rozgrzebane”. Następnie uruchamiamy git pull żeby pobrać zmiany z serwera. Jeśli pracujemy na „swojej” gałęzi (gdzie zaraz utworzymy merge request do np. developa), sam git pull nie ma sensu więc pobierzmy i scalmy zmiany z gałęzi docelowej, np. develop na remote o nazwie origin przy pomocy git pull origin develop. Teraz rozwiązujemy ewentualne konflikty w IDE. W konsoli kończymy merge zgodnie z zaleceniami GITa (jeśli były konflikty). Tym sposobem możemy spokojnie odpalić git push lub (dla nowej gałęzi) git push -u origin <nazwa_nowej_gałęzi_na_serwerze>. Teraz w przeglądarce tworzymy merge request który, pomijając code review, jest gotowy do merge z docelową gałęzią „jednym kliknięciem”. Oszczędzamy czas sobie i innym. Job done.
Proste flow zapisania zmian na serwer:
git status– sprawdzamy stan, by upewnić się co zakomitujemy,git commit -am "<opis>"– zapisujemy wszystkie zmiany,git pulllubgit pull <remote> <nazwa– pobieramy świeże zmiany i rozwiązujemy konflikty_gałęzi>git push– wysyłamy zmiany na serwer
Dopiero zaczynasz przygodę z GITem? Zobacz mój poradnik jak ogarnąć GITa w kwadrans lub dwa. It’s free 😉