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.