System Git wchodzi do gry, gdy funkcje zostaną sprecyzowane i dodane do harmonogramu produktu, a zespół programistyczny będzie gotowy do pracy. Cofnijmy się w tym miejscu o krok, aby przeprowadzić błyskawiczny intensywny kurs opracowywania funkcji według zasad Agile: zespoły produktowe, projektowe, QA oraz inżynierskie przeprowadzają spotkanie początkowe, w trakcie którego wypracowują wspólny oraz opracowywanej funkcji (wymagania), określają zakres projektu oraz zadania, na które trzeba podzielić funkcję, aby ją ukończyć. Te zadania — nazywane również historyjkami użytkowników — przypisuje się wówczas do poszczególnych programistów.

Jest to moment, w którym system Git zaczyna wpisywać się przepływ pracy Agile. W Atlassian tworzymy nową gałąź dla każdego zgłoszenia z osobna. Bez względu na to, czy jest to nowa funkcja, poprawka błędu czy drobne ulepszenie istniejącego kodu, każda zmiana kodu ma własną gałąź.

Tworzenie gałęzi jest proste i umożliwia zespołom łatwą współpracę w obrębie jednej centralnej bazy kodu. Gdy programista tworzy gałąź, w praktyce ma do dyspozycji własną, wyizolowaną wersję bazy kodu, w której może wprowadzać zmiany. Dla zespołu Agile oznacza to, że dzięki podziałowi funkcji na historyjki użytkowników, a następnie gałęzie, zespół programistyczny może zajmować się poszczególnymi zadaniami indywidualnie i pracować z większą wydajnością na tym samym kodzie, ale w odrębnych repozytoriach. Prace się nie dublują, a dzięki możliwości skoncentrowania się na niewielkich fragmentach prac w repozytoriach odrębnych od repozytorium głównego liczba zależności spowalniających proces programistyczny jest mniejsza.

Gdy gałęzie zostaną uznane za ukończone i będą gotowe do przeglądów kodu, system Git odegra kolejną kluczową rolę w przepływie pracy programowania Agile — zostanie wykorzystany na potrzeby testowania. Skuteczne zespoły Agile i DevOps stosują przeglądy kodu i konfigurują automatyczne testy (w ramach ciągłej integracji lub ciągłego dostarczania). Aby ułatwić przeglądy i testowanie kodu, programiści mogą w prosty sposób, za pomocą pull requestu, powiadomić innych członków zespołu, że praca wykonana w ramach gałęzi jest gotowa do przeglądu i wymaga sprawdzenia. Mówiąc wprost, pull request jest sposobem poproszenia innego programisty o scalenie jednej z Twoich gałęzi z gałęzią główną oraz poinformowania, że gałąź jest gotowa do testowania.

Dzięki odpowiednim narzędziom serwer ciągłej integracji może kompilować i testować Twoje pull requesty, zanim jeszcze je scalisz. Zyskasz w ten sposób pewność, że scalenie nie spowoduje problemów. Ta pewność generalnie ułatwia poprawianie błędów i usuwanie konfliktów, ponieważ system Git zna różnice między gałęzią a główną bazą kodu, które pojawiły się od momentu wyodrębnienia gałęzi.

W połączeniu systemu Git z metodyką Agile chodzi o wydajność, testowanie, automatyzację i ogólną zwinność. Po scaleniu gałęzi z gałęzią główną przepływ pracy Agile został ukończony. W podobny sposób scalenie kodu za pomocą pull requestów oznacza, że gdy kod będzie ukończony, będziesz dysponować dokumentacją potwierdzającą, że Twoja praca dostała zielone światło, że inni członkowie zespołu zatwierdzili kod oraz że ten kod jest gotowy do wydania. To pozwala zespołom Agile posuwać prace naprzód w dużym tempie, z gwarancją częstych wydań, co jest cechą wyróżniającą fantastyczne zespoły Agile.