Git – gałęzie

Wiecie już jak zacząć pracę z Gitem oraz jak rozwiązywać konflikty. Nadszedł czas na pracę z gałęziami.

 

Słowem wstępu

Gałąź to nic innego jak kopia jakiegoś commita, która jest rozwijana niezależnie. Co to oznacza? Mając główną gałąź (domyślnie jest to master) i gałąź np. dev możemy pracować na obu nie mieszając niczego ze sobą aż do chwili gdy będzie nam to potrzebne. Możemy np. rozwijać jakąś funkcjonalność na gałęzi dev i jednocześnie na masterze (a najlepiej na jeszcze jednej osobnej gałęzi) robić np. szybkie fixy dla wykrytych bugów.

Przy pracy samodzielnej praca na gałęziach może wydawać się mało wartościowa, bo ktoś może stwierdzić, że przecież można pracować na masterze a w razie potrzeby zrobić „git stash” i zrobić fixa a potem przywrócić zawartość schowka. Można tak pracować i jeśli komuś to odpowiada to ma takie prawo. Wyobraźmy sobie sytuację, w której tworzymy nową funkcjonalność na masterze i w trakcie stwierdzamy, że chcemy odłożyć to na później a teraz chcemy zając się czymś innym. Oczywiście można znowu użyć schowka ale co jeśli i teraz pojawi się jakiś bug? Dlatego nawet jeśli wydaje się to niepotrzebne to i tak zalecam korzystanie z gałęzi 🙂

Wszystko fajnie obrazuje pewne zdjęcie ze strony nvie.com

 

Nasza gałąź

Aby wyświetlić aktualne gałęzie używamy polecenia

co w chwili obecnej zwróci nam

Mamy tutaj nazwę naszej głównej gałęzi i * przed nazwą. * oznacza, że dana gałąź jest aktualnie używana.

Możemy też użyć polecenia z opcją „-v” by zobaczyć ostatnią zatwierdzoną zmianę w każdej gałęzi

 

Nowa gałąź

Zacznijmy od utworzenia nowej gałęzi o nazwie „dev” (dla wszystkich prac deweloperskich). Możemy to zrobić poleceniem

gdzie „dev” na końcu to nazwa naszej gałęzi. Otrzymamy (w kolejnych przykładach pierwsza linijka to polecenie a kolejne to wynik tego polecenia 😉 )

Aby przejść na nową gałąź używamy

Można też utworzyć nową gałąź i przełączyć się na nią jednym poleceniem (bez łączenia komend)

 

Praca

Przypuśćmy, że naszą nową super funkcją będzie dodanie nowego pliku

Chcielibyśmy dodać jeszcze kilka linijek ale okazało się, że w naszym pierwszym pliku jest błąd. W pliku mamy

a miało być

Oczywiście jest to na tyle poważny błąd, że musimy poprawić to natychmiast.

 

W tym celu potrzebujemy wrócić do naszej głównej gałęzi. W naszym przypadku zmiana poleceniem

pozwoli nam na zmianę gałęzi bez żadnych przeszkód. Niestety często taka operacja skończy się komunikatem (xyz to lista zmienionych plików)

W takiej sytuacji mamy dwa wyjścia: możemy zatwierdzić zmiany lub skorzystać ze schowka.

 

Będą na gałęzi master możemy albo naprawić nasz błąd na tej właśnie gałęzi albo na gałęzi dedykowanej. Wybierzmy drugą opcję i utwórzmy gałąś „issue1” (i od razu na nią przejdźmy)

Możemy teraz wprowadzić zmiany w pliku „plik.txt”

i jeśli po „przetestowaniu” wszystko jest w porządku możemy zatwierdzić zmiany

Dodając do polecenia „git commit” parametru „-a” (w naszym przypadku połączyliśmy „-a -m” w „-am”) omijamy konieczność użycia polecenia „git add”. Jedynym minusem tego jest to, że zatwierdza zmiany tylko w modyfikowanym pliku lub usuniętym. Nowe pliki nie zostaną zatwierdzone.

 

Wracamy na naszą główną gałąź

i przenosimy zmianę na „mastera” poleceniem

„issue1” to nazwa gałęzi którą chcemy scalić z aktualną gałęzią.

Jako, że problem rozwiązaliśmy i gałąź „issue1” nie jest nam już potrzeba to możemy ją usunąć za pomocą

Jest to wersja bezpieczna – jeśli gałąź nie została scalona pojawi się komunikat

i gałąź nie zostanie usunięta. Jeśli pracowalibyśmy nad jakąś funkcjonalnością i stwierdzilibyśmy, że jednak jej nie chcemy to możemy usunąć gałąź bez scalania za pomocą sugerowanego polecenia

 

Teraz możemy wrócić na naszą gałąź „dev”

Dobrze byłoby tutaj też scalić wprowadzoną poprawkę

 

Jeśli przed opuszczeniem gałęzi „dev” skorzystalibyście ze schowka to do odzyskania jego zawartości używamy

Jak widać pojawił się konflikt. Musimy edytować plik „plik.txt”, który wygląda tak:

poprawiamy na:

i zatwierdzamy zmiany

(jeśli użyliśmy schowek)

(lub bez schowka)

 

Na koniec (jeśli jesteśmy zadowoleni ze zmian) przechodzimy na mastera i scalamy

I jeszcze małe podsumowanie

 

W razie pytań zapraszam do komentarzy 🙂


Post 3 z 5 z serii Git
  • Nvie – dokładnie tak wygląda moje aktualne git workflow 😉 Fajnie jest to opisane również tutaj: https://www.atlassian.com/git/tutorials/comparing-workflows. Bazowałam na tym, gdy pierwszy raz potrzebowałam bardziej zaawansowanego systemu. Bo bądź co bądź przy mniejszych projektach rzeczywiście można sobie bazować na masterze, ew. dev’ie, ale bez zabawy z pozostałymi branch’ami 🙂 Ale przy większych projektach… prędzej czy później trzeba rozbudować system. I Gitflow sprawdza się moim zdaniem świetnie 😉

    Fajny artykuł! Wiem już gdzie odeślę w swoim po więcej szczegółów i informacji 😉

    • Dzięki 🙂
      Jak zaczynałem pracę to dostałem właśnie ten artykuł z Nvie 😀
      Z Atlassian też już kiedyś czytałem – bardzo fajny.

      Co do mniejszych projektów to sytuacja jak z wszystkim – trzeba dostosować do własnych potrzeb i preferencji.