Git to najpopularniejszy system kontroli wersji. Pomaga hordom programistów pracować lepiej, wydajniej i bardziej elastycznie. Pomimo że liczy sobie już ponad trzynaście lat, wciąż wiele osób używa go źle, zabijając w ten sposób produktywność. Problem ten objawia się głównie przy pracy z branczami i koniecznością merdżowania. Oczywiście przed gitem istniały gałęzie, ale tworzenie ich było ciężkie. On to zmienił. Umożliwił łatwe i szybkie tworzenie branczy przez każdego. Co niejednokrotnie skutkuje katastrofą. Czego zatem nie robić? Przedstawię dziś kilka antywzorców jak nie branczować.

Branch per story

Założeniem tego podejścia jest, aby każda historyjka, na czas developmentu, była implementowana na osobnej gałęzi. Następnie, po etapie testów zatwierdzona i złączona z główną gałęzią. Idea brzmi dobrze, ale praktyka pokazuje, że to nie może się udać. Jest ku temu kilka powodów:

  • Historyjki są tworzone przez osoby nietechniczne w taki sposób, aby klient wiedział, co się dzieje i na jakim etapie projektu jesteśmy.
  • Jedne zadania zależą od innych. Podejście branch per story wymusza, aby wstrzymać pracę nad zadaniem, aż do całkowitego zakończenia poprzedniego. Oczywiście można brać do sprintu tylko zadania od siebie niezależne, ale rzeczywistość się na to nie zgadza.
  • Jak wiele zadań może być w sprincie. Kilkanaście? Co wtedy? Należy odbić gałąź dla każdego zadania, a na koniec dziwić się wysypem merdży.

Branch per developer

Nie mam pojęcia, kto mógł wymyślić coś takiego. Wygląda to tak. Każdy dev zakłada swoją gałąź, aby cały czas programować mając święty spokój. Wspaniale? Tylko na pierwszy rzut oka. Czas merdża musi nadejść! Wszystkie zmiany należy wepchnąć do mastera. Ze względu na długie kiszenie kodu, rozwiązywanie konfliktów to męczarnia.

Branch per sprint

W takim rozwiązaniu są dwa brancze: current i previous. Na koniec sprintu gałąź current łączymy z previous, aby zamrozić aktualną wersję. W celu przygotowania klientowi stabilnego dema, nie blokując pracy zespołu. Czyli dobrze? Nie do końca. Ponieważ ten sposób:

  • Jest wymuszony przez sposób współpracy z klientem, a nie z powodu optymalizacji pracy.
  • To tylko obejście lub nadmiarowy proces. Można to rozwiązać bardziej standardowo. Odbijając release brancz dla klienta oraz dobrą konfiguracją CI.

Git flow

Jest to najpopularniejsza strategia branczowania. Dlaczego uważam, że jest z nią coś nie tak? Ze względu na swoją popularność jest wdrażana w zbyt wczesnych fazach projektów. Kiedy refaktoring i zmiany koncepcji są na porządku dziennym. W takiej sytuacji jest to zbyt ciężka droga, narzucająca wiele ograniczeń i wymagająca, bądź co bądź, sporo merdżowania.

Podsumowanie

Git to świetne narzędzie pozwalające na wiele. Jednak zawsze znajdzie się ktoś, kto użyje go niezgodnie z przeznaczeniem. Czy powinniśmy go ograniczać? Idąc tym tokiem rozumowania, należałoby sprzedawać tylko tępe noże i zabronić jazdy autami, bo czasem ktoś źle ich użyje. Drogi programisto przed podjęciem decyzji o sposobie branczowania w Twoim projekcie zastanów się, czy nie można zrobić tego prościej. Natomiast jeżeli już w twoim projekcie macie z tym problem to warto coś zmienić. W każdym razie, czy masz może jakieś porady jak nie używać gita? Jeżeli tak to zapraszam do dyskusji w komentarzach.



Podobało Ci się?

Zapisz się i nie przegap kolejnych postów.


2 Komentarze

Nick · 2018-06-25 o 16:28

Dlaczego poza wadami poszczególnych podejść w tekście nie ma żadnych sugestii jak je poprawić ?

    Jerzy Wickowski · 2018-06-25 o 17:01

    Hejka.
    Z dwóch powodów. Po pierwsze, jeżeli unikniesz tych podejść, to już będziesz w dobrej sytuacji. Po drugie, chcę o tym wrzucić inny post :).

    Jeżeli jesteś ciekawy dobrych podejść, to uważam, że trzy są warte rozważenia:
    – Trunk based – na starcie projektu i po wdrożeniu, jeżeli wystarczy.
    – Git flow – kiedy już jest na produkcji i trunk based nie wystarcza.
    – Master only – przy projekcie z działającym Continous Delivery.

Dodaj komentarz

Twój adres email nie zostanie opublikowany.