Druga część naszego tutoriala. Dzisiaj zajdziemy do lasu i pobawimy się gałęziami. ;]
Rozproszone systemy kontroli wersji, przez swoją specyfikę, mają nijako wymuszone łatwe zarządzanie gałęziami oraz ich łączenie. Nie inaczej jest z gitem. Własną gałąź najprościej utworzyć tak:
I tym sposobem zrobiliśmy nową gałąź o nazwie dev. Teraz możemy się do niej przełączycz wydając polecenie:
Możemy również cały proces zautomatyzować dodając do checkout parametr -b, dzięki czemu jednocześnie zostanie utworzona gałąź o odpowiedniej nazwie (bez wydawania polecenia branch) i zostaniemy do niej przeniesieni. Teraz edytujemy nasz projekt, commitujemy (inaczej git nie pozwoli na zmianę gałęzi (chyba, że dodacie odpowiednie parametry, o których możecie przeczytać tutaj), ew. zmiany przeniesie do docelowej gałęzi, jeżeli obecna wywodzi się z docelowej) i przełączamy się do gałęzi głównej (master) aby zobaczyć, że faktycznie w masterze nie ma tego co było w dev.
Jednak branche nic nie znaczą, jeżeli nie da się ich połączyć. W gitcie służy do tego polecenie merge (wcześniej przechodzimy do gałęzi do której chcemy zmergeować inną gałąź):
Jeżeli gałąź którą chcemy zmergeować wywodzi się z tej, do której chcemy łączyć (a nie wprowadzaliśmy w niej żadnych zmian), wtedy przesuwane jest tylko oznaczenie gałęzi (nazywa się to fast-forward). Może się czasami zdarzyć, że trafił się nam konflikt, wtedy wystarczy wyedytować plik w którym się on znajduje (konkretne kawałki kodu są dobrze oznaczone) oraz commitować zmiany.
Oprócz możliwości łączenia gałęzi możemy jeszcze połączyć dwie gałęzie w jedną. Służy do tego polecenie rebase:
Gałęzie przed wydaniem polecenia rebase:
/
A-----------E master
Oraz po:
Cała gałąź dev zostanie przepisana i wstawiona w inne miejsce. Nie są to dokładnie te same commity (choć jak sie spojrzy przez diff to wyglądają tak samo), ale ze względu na inne ułożenie w gałęzi są z puktu widzenia gita troszeczkę inne.
Kolejnym ciekawym poleceniem jest cherry-pick. Pozwala ono na utworzenie nowego commita dla danej gałęzi, który będzie w sobie zawierał wszystkie commity począwszy od oznaczenia gałęzi aż do commita podanego jako argument. Dzięki temu możemy utrzymać większy porządek w naszym drzewie.
To tyle z działu gałęzi. Jeżeli ktoś chce pogłębić swoją wiedzę to zapraszam do czytania dokumentacji. Jest bardzo prosto napisana i nie powinna sprawić nikomu problemu. Polecam również narzędzie gitk z parametrem –all, które jest świetnym, graficznym podglądem ułożenia gałęzi w projekcie.
