Od samego początku organizujemy nasze repozytoria tak, aby odpowiadały potrzebom naszej metody pracy z kodem. Używamy dwóch głownych gałęzi (master i development) oraz wielu dodatkowych gałęzi odpowiadających funkcjonalnościom i poprawkom. Gałąź master odzwierciedla kod środowiska produkcyjnego, natomiast development jest odniesieniem wewnętrznego środowiska programistycznego. Dla każdej nowej funkcjonalności tworzymy odrębną gałąź łącząc ją z elementem backlogu. To podejście pozwala lepiej monitorować postępy. Używamy również ustandaryzowanego nazewnictwa, co pozwala lepiej rozróżniać gałęzie i ich cele. Istotne kroki milowe zamrażamy w formie tagów.
Dajemy pełną wolność wyboru naszym programistom co do używanego IDE i edytora tekstowego ponieważ mamy dobrze ustandaryzowane wymagania dotyczące kodu. Przestrzegamy wewnętrznych standardów dotyczących nazewnictwa, formatowania, ponownego użytkowania kodu, struktury kodu, architektury, organizacji plików w projekcie. To wszystko pozwala nam tworzyć jednolity, czysty i wydajny kod. Używamy głównie dwóch podejść do projektowania rozwiązań w zależności od potrzeb projektowych - FDD (feature driven development) lub TDD (test driven development). Stawiamy również mocno na wzorce projektowe. Na koniec kod refaktoryzujemy i używamy linterów, żeby pozostał optymalny, spełniał nasze standardy i zaspokajał wszystkie potrzeby projektowanego rozwiązania.
Każda linia kodu, którą dodajemy do naszych głównych gałęzi jest podwójnie sprawdzana. Wykorzystujemy metodę krzyżowych weryfikacji przez programistów. Sprawdzamy kod z wielu perspektyw - od kwestii architektonicznych, przez strukturę, złe wzorce, problemy z nazewnictwem i formatowaniem po literówki. Dzięki temu możemy wyłapać potencjalne zagrożenia na etapie projektowym, zoptymalizować kod i uczynić bezpieczniejszym jeszcze przed etapem testów. Zdarza się, że musimy czasem wycofać zmiany i przemyśleć sposób rozwiązania usuwając pull request. Ale lepiej jest zrobić to na etapie przeglądania kodu, niż stwarzać problemy na produkcji.
Ostatnim krokiem, a zarazem najważniejszym krokiem jest testowanie. Podczas developmentu kod przechodzi testy jednostkowe i integracyjne. Następnie używamy testów automatycznych z przygotowanych wcześniej scenariuszy i testów manualnych. Jeżeli wszystko pójdzie bezbłędnie jesteśmy gotowi złączyć kod z gałęzią developerską i przygotować drugi pull request do środowiska produkcyjnego, gdzie kod z wielu gałęzi zostanie poddany ponownie procesowi testowania.