Blog

Dziś porównamy dwa odmienne podejścia do używania narzędzia, jakim jest system kontroli wersji Git. Pierwszym podejściem jest git flow, który dawno już podbił serca użytkowników Gita. Drugi to development oparty o gałąź główną, który wkracza na salony wraz ze wzrostem popularności Ciągłego Dostarczania Oprogramowania (CD).

Git – kontrola i szybkość

Git ma swoje korzenie w projektach otwartoźródłowych – konkretnie w Linuxie. Projekty Open Source mają swoją specyfikę – każdy może mieć w nich swój wkład. Każdy. Zmiany w taki sam sposób proponuje developer z 30-letnim stażem, co student pierwszego roku.

Nie mamy żadnej wiedzy na temat danego autora zmian. Nie możemy zatem ufać, że wie, co robi. W związku z tym musimy kontrolować. W takim przypadku lepszym wyborem będzie git flow, ze względu na moment zatrzymania – pull request. Dopóki kontroler, zazwyczaj kilka osób, nie zaaprobuje zmian, nie będą one miały szansy wyrządzić żadnych szkód.

Kontrola odbywa się jednak kosztem szybkości. Żeby skontrolować, potrzeba czasu i biurokracji. Gdy pracujesz w niedużym zespole z wprawnymi programistami, takie ciągłe przestoje, tylko po to, aby usłyszeć lub napisać „dobra robota!”, są marnotrawstwem. Lepiej zastosować trunk-based development. Zmiany wrzucamy od razu do pnia.
Naturalnie może się zdarzyć, że się pomylimy i zepsujemy kompilację, ale kod naprawczy wrzucamy co najmniej tak szybko, jak sam błąd. Bo błąd musi być w najświeższej zmianie, a ponieważ zmiany są małe, to pole poszukiwań jest znikome.

Optymalność i Ciągła Integracja

Zarówno git flow, jak i trunk-based development są optymalne. Git flow jest optymalny dla programisty – bierzesz swoje zadanie, idziesz do swojej klawiatury i rzeźbisz w ukryciu, aż w końcu będziesz zadowolony ze swojego dzieła. Nic wcześniej nie musisz pokazywać, tylko doklejać co jakiś czas to, co inni w międzyczasie skończyli rzeźbić. Development oparty o pień jest optymalny dla zespołu – cokolwiek nie zostanie zrobione, wszyscy od razu mogą z tego korzystać. Wszystko jest aktualizowane w sposób ciągły. Dlatego też trunk-based developement jest najbardziej naturalnym sposobem pracy z Git, gdy chcemy osiągnąć Ciągłą Integrację i w dalszej perspektywie Ciągłe Dostarczanie. Git flow, a w szczególności długo żyjące gałęzie, mogą prowadzić do maskary scalania zmian (merge hell) i przeciągającej się fazy integracji.

Które podejście wybrać?

Jeśli możemy sobie pozwolić na dużą dozę zaufania, czyli najczęściej mamy po prostu nieduży zespół seniorów, to śmiało możemy iść w trunk-based development. Gdy zespół jest bardzo duży albo dużo w nim osób z małym doświadczeniem, albo produkt jest z gatunku „każda zmiana grozi zawaleniem”, to warto rozważyć git flow. To takie czarno-białe przykłady. W realu trzeba pamiętać, że to tylko narzędzia i najprościej w świecie mają nam życie ułatwiać. To, co dla innych jest świętą praktyką, u nas wcale nie musi działać. Dla przykładu: w projektach Open Source zazwyczaj pull request musi zostać zatwierdzony przez co najmniej dwie osoby. Ale w zespole, w którym się znamy, codziennie rozmawiamy na standupie, zatrudnialiśmy się wzajemnie itd., być może jedna para oczu zupełnie wystarczy.

Jak widać, to samo narzędzie – Git – może być używane na różne sposoby. I oczywiście jeden z tych sposób jest lepszy. Który, zależy od konkretnej sytuacji i takich czynników jak rodzaj projektu, czy wielkość i skład zespołu developerskiego.