Praca w grupie nad projektem oraz praca na gałęziach w Git czy SVN to synonimy. Nie da się pracować efektywnie nad projektem w kilka osób, bez systemu kontroli wersji, jakim jest GIT i SVN. Który lepszy, który gorszy, pozostawiam do waszej oceny, a o wprowadzeniu do systemów kontroli wersji możesz przeczytać tutaj. Ja używam w projektach głównie GIT-a, dlatego o tym będzie ten wpis.

git praca na gałęziach

Teoretycznie, korzystając z systemów kontroli wersji można pracować tylko i wyłącznie na jednej gałęzi, lecz jeśli aplikację rozwija kilka lub więcej osób, na gałęzi tworzony jest, najprościej mówiąc, syf i bajzel. Lwia część programistów dba o estetykę kodu, o znormalizowane i spełniające powszechne konwencje nazewnictwo klas, zmiennych i funkcji, a pomija estetykę dokumentacji. I nie mówię tu o opisach, diagramach itp., bo taka dokumentacja nie zawsze jest potrzebna, ale jeśli chodzi o GIT-a, to sprawne zarządzanie branchami może nam kilkukrotnie przyspieszyć pracę nad aplikacją.

GIT jest przystosowany do pracy na wielu branchach, czyli gałęziach, a skoro tak, warto się zastanowić, dlaczego twórcy tak mocno ułatwili korzystanie z tej funkcjonalności względem innych VCS-ów (VCS – ang. Version Control System). Odpowiedź jest prosta. Możliwość i łatwość zarządzania gałęziami pozwala nam na dostosowanie pracy z gitem do naszego projektu i zespołu, aby jak najbardziej zwiększyć efektywność naszej pracy. I nie ma tu zupełnie znaczenia, czy zadaniem Twojego zespołu jest tworzenie aplikacji internetowych, programów desktopowych, czy zupełnie innych projektów.

Jeśli pracujesz nad projektem sam, śmiało możesz korzystać tylko z głównej gałęzi, jaką jest „master” (co też zresztą odradzam, bo dobre nawyki przyswaja się powoli i warto to robić już od małych prywatnych aplikacji). W przypadku pracy w pojedynkę, commity są wrzucane po kolei wraz z rozwojem programu. Różnice w plikach można podejrzeć i najczęściej widać jasno, że funkcja po funkcji Twoja aplikacja się rozrastała. Co jednak, jeśli nad projektem pracuje jeszcze druga osoba, i nie zatwierdzacie swoich zmian po kolei? Twoje commity mieszają się z commitami drugiego pracownika, próbując skorzystać z komendy diff musicie się zdrowo nagłowić, by domyśleć się, które zmiany za co odpowiadają i w jakiej kolejności były dodawane funkcje. To teraz dodaj do tego jeszcze 5 osób. Co Ci wychodzi, bo mi Sodoma i Gomora.

Właśnie po to GIT posiada branches – czyli po prostu gałęzie. Gałęzie to funkcjonalność tak elastyczna, że praca na branchach może być prowadzona na kilka różnych sposobów. Poniżej przedstawiam pierwszy model pracy na gałęziach, w przyszłych postach opiszę jeszcze kilka z nich. To, z których z nich skorzystasz przy swoich projektach zależy wyłącznie od zespołu z którym pracujesz oraz projektu, nad którym działasz.

Praca na gałęziach

Model, który zamierzam teraz opisać, wykorzystuje 4 gałęzie: master, develop, feature, i bug. Tak, wiem, konwencja, którą wprowadzam jest angielska, poza tym mieszam angielskie słówka z polskimi w artykule napisanym po polsku, ale do tego się po prostu przyzwyczaj – wszelkie słowa kluczowe używane w programach będę pisał bez niepotrzebnych tłumaczeń. Zacznę od opisu każdej z wykorzystywanych gałęzi, rozpoczynając od tej najbardziej szczegółowej, a kończąc na tej, która będzie aktualizowana najrzadziej.

Gałąź feature

Jest to gałąź wykonywanych zadań. Kiedy jedna osoba z naszego zespołu otrzymuje zadanie do wykonania, kolejne swoje commity wrzuca właśnie tutaj. Przykładowo załóżmy, że zadanie „stworzenie szkieletu aplikacji” opiera się na utworzeniu kilku klas i nawiązaniu relacji między nimi. Być może wymagało to od nas kilku aktualizacji repozytorium GIT. Jeżeli wszystko wrzucać będziemy na gałęzi master, w krótkim czasie w repozytorium utworzy się bałagan, nad którym nikt z nas nie będzie panować. Proponuję więc wszystkie cząstkowe commity wrzucać na branch feature, a ukończone zadanie dopiero na bardziej ogólną gałąź. Na feature programiści pracują głównie lokalnie – gałąź ta służy niemal wyłącznie do pushowania. Nie należy pobierać z niej aktualizacji, bo istnieje duże prawdopodobieństwo, że kod, który ktoś wrzucił nie współgra z naszym, aplikacja nie będzie się kompilować, albo będzie błędnie działać.

feature branch git

Gałąź feature odpowiedzialna za przechowywanie informacji o wykonywanym zadaniu.

 

Praca na gałęziach feature może się odbywać na dwa sposoby. Pierwszym jest wspólna gałąź, służąca jedynie do uploadu, na której wykonywane są wszystkie zadania jednocześnie. Powoduje to pewien bałagan, lecz w tej konwencji gałąź develop odpowiada za informacje o poszczególnych zadaniach.

Weźmy przykład. Pracownik rozpoczyna zadanie. Przystępuje więc do pracy, pobierając ostatnie kompatybilne dane z gałęzi develop.

Następnie przełącza się na lokalną branch feature, łączy ją z develop i kolejne aktualizacje swojej pracy wrzuca już na gałąź feature.

W między czasie inny programista dostaje zlecenie wykonania innego zadania. Wykonuje więc dokładnie te same kroki, pobierając dane z develop, i rozpoczynając równoległą pracę na feature. W momencie, gdy któryś z nich ukończy zadanie, wykonuje merge z gałęzią develop i kolejni koderzy mogą korzystać już z bardziej aktualnego kodu.

Drugim sposobem wykorzystania gałęzi feature w pracy z GIT-em jest potraktowanie feature jako słowa oznaczającego nazwę danego zadania. W ten sposób każde zadanie tworzone jest na innej gałęzi. Umożliwia to zachowanie większej przejrzystości w pracy oraz łatwiejszego rozeznania, jak powstaje aplikacja. Dzięki takiemu rozwiązaniu każdy z programistów w dowolnej chwili może przełączać się na gałęzie innych członków zespołu, pobierać ich aktualne wersje, pomagać przy problemach, korzystać z pomocy innych… niesamowite ułatwienie.

Przykład

Gałęzie nazywane od poszczególnych zadań są usuwane w momencie mergowania ich z gałęzią develop, czyli po ukończeniu zadania.

Gałąź develop

Główna gałąź programowania. Wrzucane są na nią wyłącznie commity z (wstępnie?) ukończonych zadań. Jaki jest sens tego rozwiązania? Otóż, kiedy programista otrzymuje zadanie do wykonania, ma możliwość szybkiego pobrania ostatniej działającej wersji programu z zaimplementowanymi wszystkimi ukończonymi do tej pory zadaniami. Nie musi się przejmować pracę innych członków zespołu tylko od razu może przystąpić do tworzenia rozwiązania nad swoim taskiem, a po jego ukończeniu korzystając z dobrodziejstw GIT-a połączyć swoją pracę z ukończonymi w międzyczasie zadaniami reszty zespołu.

develop branch git

Gałąź develop, na którą wrzucane są kolejne ukończone zadania.

Gałąź bug

Jest to branch odpowiedzialny za usuwanie wykrytych w aplikacji błędów. Nie tworzymy tutaj nowych tasków, jedynie usuwamy błędy w zadaniach już wstępnie zakończonych, jest to więc gałąź równoległa do gałęzi feature. Ta gałąź także nie powinna służyć do tego, by pobierać z niej aktualizacje, lecz niemal zawsze wyłącznie do pushowania danych. W przypadku bugów nie ma potrzeby tworzenia różnych gałęzi dla różnych błędów – jeśli błąd okaże się bardzo rozległy, można go potraktować jako dodatkowe zadanie i przeprowadzić je na gałęzi z nazwą tego problemu.

gałąź bug git

Gałąź odpowiedzialna za usuwanie błędów. Po usunięciu buga jest łączona wstecz z develop.

Gałąź master

Gałąź najrzadziej używana – jest aktualizowana wyłącznie przez CTO projektu, gromadzone są na niej jedynie kolejne produkcyjne wersje aplikacji. Na gałęzi master istnieje możliwość tworzenia węzłów nie będących kolejnymi wersjami, lecz ma to zastosowanie jedyniew przypadku wykrycia bardzo poważnych błędów, na przykład konfiguracyjnych.

gałąź master git

Gałąź master – główna gałąź aplikacji przechowująca kolejne wersje produkcyjne aplikacji.

Model pracy z gałęziami w GIT – podsumowanie

Praca na gałęziach w GIT może nam w znacznym stopniu pomóc w zarządzaniu budową projektu, ułatwić komunikację w zespole oraz przyspieszyć budowę aplikacji. Jedynym mankamentem jest nauczenie się, jak z tego systemu korzystać. Najlepszy tutorial tekstowy jaki znam w języku polskim odnośnie GIT-a znajdziesz tutaj, ale nie wyjaśnia on tego, jak efektywnie wykorzystać GIT-a w praktyce. Mam nadzieję, że tym wpisem pokazałem, że nie jest to coś trudnego, a wręcz przeciwnie, coś, co sprawia że cała budowa projektu staje się łatwiejsza.

Poniżej zamieszczam jeszcze kompletny schemat naszego modelu. Mam nadzieję, że pomoże ci to lepiej zrozumieć model wykorzystania gałęzi do pracy z GIT-em.

praca na gałęziach git

Kompletny schemat wykorzystania gałęzi master, bug, develop i feature.

Pamiętaj o podzieleniu się opinią o tym modelu w komentarzach. Jestem świadom, że praca na gałęziach w Git jest sprawą indywidualną zarówno dla programisty, zespołu, jak i projektu, którym się zajmujesz, chcę Ci tu jednak wskazać pewien kierunek, jak te gałęzie w ogóle ugryźć. Widzisz jakieś niejasności w przedstawionym modelu, albo znasz lepszy? Opowiedz mi o tym. Jeśli artykuł Ci się podobał, śmiało kliknij w G+ lub like/share i udostępnij go znajomym. Pamiętaj też, że liczę na twój komentarz w tej kwestii.

Pin It on Pinterest

Share This
Sekrety Produktywności

Sekrety Produktywności

DARMOWE szkolenie mailingowe! 10 porad jak zwiększyć produktywność w programowaniu.

Dziękujemy za zapisanie się na kurs. Wkrótce otrzymasz wiadomość email z potwierdzeniem zapisu.

FreshMail.pl