Cześć.

Po ostatniej krótszej notce dzisiaj coś hmm… trudniejszego? Ale tylko teoretycznie. W praktyce rzecz łatwa i bardzo porządkująca projekt. Dzisiaj branching.

Co to takiego ten tajemniczy branching? Ano nic innego jak rozdzielanie poszczególnych części projektu nad którymi prowadzone są prace od siebie nawzajem oraz od gałęzi głównej, czyli „najlepszej” wersji aplikacji. Wyobraź sobie drzewo. Drzewo składa się z pnia i gałęzi od niego odchodzących. Pień jest jakby najstarszą i najsilniejszą gałęzią. W gicie jest nim master, bo tak przyjęto nazywać gałąź główną. Master to gałąź z najbardziej zaawansowaną częścią aplikacji, ale zawierającą tylko działające elementy. Najprościej zobaczyć to na przykładzie gotowej aplikacji. W gałęzi master będzie to co znajduje się na produkcji. Pozostałe gałęzie to jakieś wdrażane obecnie części aplikacji. Podobnie jak w drzewie od gałęzi mogą odchodzić inne gałęzie.

Wydaje się to trochę zawiłe, ale spójrz jak to wygląda w praktyce. Stworzyłem gotową stronę internetową dla klienta i wdrożyłem ją. Cały kod aplikacji w repozytorium gita znajduje się na gałęzi master. Klient zdecydował, że w nowej zakładce będzie sklep. Zaczynam tworzyć taki sklep na nowej gałęzi – shop. W międzyczasie klient zdecydował, że na którejś z podstron wprowadzone mają być jakieś zmiany. Sklep już prawie działa, pozostały drobnostki do poprawy i grafika, ale te zmiany są ważniejsze. Więc na nowej gałęzi stworzonej od gałęzi głównej wprowadzam te zmiany, a grafik koduje wygląd sklepu na gałęzi odchodzącej od gałęzi shop. Po skończonej pracy łączę gałąź na której pracowałem z masterem i wrzucam poprawki na stronie klienta, po czym wracam do pracy nad sklepem. Łącze gotowy kod od grafika z moim kodem dołączając jego gałąź do gałęzi shop, kończę sklep i łączę moją gałąź z masterem. Proste prawda?

A teraz jak to zrobić w gicie? Nic prostszego. Z wykorzystaniem komendy

git checkout nazwa_gałęzi

Aby utworzyć nową gałąź należy użyć polecenia

git branch nazwa_nowej_gałęzi

Na nowej gałęzi znajdziesz dokładnie to samo co na tej, na której aktualnie się znajdujesz. Pamiętaj jednak, że takie stworzenie gałęzi nie powoduje automatycznego jej użycia. Musisz na nią przejść tak jak napisałem powyżej. Aby tego uniknąć, utworzyć gałąź i od razu na nią przejść użyj

git checkout –b nazwa_nowej_gałęzi

Oczywiście istnieje możliwość usunięcia gałęzi. Aby to zrobić użyj opcji -d

git branch –d nazwa_gałęzi

O ile przy małym projekcie nie ma problemu, to przy nieco większym możesz mieć problem z zapamiętaniem jakie gałęzie stworzyłeś. Możesz to sprawdzić używając

git branch –v

Najprostszym sposobem łączenia gałęzi jest użycie funkcji merge na gałęzi do której chcemy inną gałąź dołączyć. Jeśli natomiast napiszemy stek bzdur można użyć opcji checkout, żeby zrównać wszystko do poziomu innej gałęzi.

git merge nazwa_gałęzi
git checkout nazwa_gałęzi

Pamiętaj że po połączeniu gałęzi skasowanie jej jest możliwe jedynie z opcją force, czyli w opcji zamiast -d należy użyć -D.

Oczywiście na zewnętrzne repozytoria nie trafia jedynie gałąź główna, ale również pozostałe. Aby wysłać zmiany z tylko jednej, konkretnej gałęzi należy podać jej nazwę w poleceniu push.

git push origin nazwa_gałęzi

Pobieranie jest nieco bardziej skomplikowane. Można to zrobić na dwa sposoby. Pierwszy z użyciem funkcji fetch zapewnia pobranie gałęzi, ale nie będzie można na nich wprowadzić żadnych lokalnych zmian. Drugi, z użyciem pull taką możliwość już zapewni.

git fetch origin
git pull origin nazwa_gałęzi

Wcześniej wspomniałem, że najprostszym sposobem na dołączenie nowej gałęzi do starej jest opcja merge. Nie rozpisywałem się o niej specjalnie, ponieważ nie używa się jej zbyt często. Używa się natomiast opcji rebase, która jest nieco bardziej zaawansowana.

git rebase nazwa_gałęzi

Jeśli dwie osoby dokonały zmian na tym samym pliku, to osoba, która później wykonuje rebase, jest odpowiedzialna za poprawne działanie programu, czyli decyzję, czyj kod ma zostać. W skrócie działa to tak, że git przeszukuje zmiany po commitach. Jeśli w jakimś pliku dokonana została wcześniej zmiana (ale po stworzeniu aktualnie dołączanej gałęzi) to git zatrzymuje proces, wyświetla pliki, które zostały kolejny raz zmienionej i zaznacza fragmenty w kodzie. Użytkownik, który wykonuje rebase decyduje, czy zostawia swój fragment kodu, ten który istniał czy oba. Po zapisaniu zmian w plikach wykonuje polecenie

git rebase --continue

I tak commit po commicie. W większych projektach warto zatem robić przemyślane commity, żeby nie okazało się, że będzie konieczność zmieniać kilkunastokrotnie jedną i tą samą rzecz w tym samym pliku.

Po tej operacji ponowne wysłanie gałęzi na serwer musi odbyć się z opcją --force.