Przepływy pracy Git dla profesjonalistów: dobry przewodnik po Git

Git może wesprzeć Twój projekt nie tylko kontrolą wersji, ale także współpracą i zarządzaniem wydaniami. Zrozumienie, w jaki sposób wzorce przepływu pracy Git mogą pomóc lub utrudnić projekt, da ci wiedzę potrzebną do efektywnej oceny i dostosowania procesów Git w projekcie.

W tym przewodniku będę izolował wzorce procesu tworzenia oprogramowania, które można znaleźć w typowych przepływach pracy Git. Znajomość tych zagadnień pomoże Ci znaleźć kierunek przy dołączaniu, tworzeniu lub rozwijaniu zespołu programistów. Zalety i wady niektórych typów projektów lub zespołów zostaną wyróżnione w analizowanych przez nas przykładach przepływu pracy, abyś mógł wybrać to, co może dobrze pasować do Twojego scenariusza.

To nie jest wprowadzenie do korzystania z Git. Istnieją już wspaniałe przewodniki i dokumentacja na ten temat. Skorzystaj z tego przewodnika po przepływie pracy Git, jeśli masz już doświadczenie w zespole programistów aplikacji i napotkałeś problemy z przepływem pracy, implozje integracji lub git-tastrofy — te wzorce mogą rzucić nieco światła na to, jak uniknąć takich sytuacji w przyszłości.

Współpraca

Jeśli chodzi o proces Git, współpraca często polega na rozgałęzianiu przepływów pracy. Myślenie z wyprzedzeniem o tym, w jaki sposób będziesz przeplatać drzewa commitów, pomoże zminimalizować błędy integracji i wesprze strategię zarządzania wydaniami.

Oddział Integracyjny

Użyj oddziału integracji z zespołami programistycznymi, które pracują nad wdrożeniem kolekcji wkładów do środowiska produkcyjnego jako pojedyncza jednostka. Jest to przeciwieństwo zespołów, które koncentrują się na indywidualnym wdrażaniu funkcji. Często zespoły mogą chcieć robić to drugie, ale praktyczne ograniczenia nakładają proces, który grupuje ich wysiłki, a zespół ostatecznie robi to drugie, więc pamiętaj, aby przejrzeć rzeczywiste użycie Git, aby zobaczyć, czy skorzystasz na korzystaniu z tego typu współpracy wzór.

Ten wzorzec przepływu pracy jest przydatnym punktem pomostowym, gdy ryzyko integracji wielu oddziałów jest wystarczająco wysokie, aby uzasadnić testowanie połączonych wkładów jako całości.

Gałąź integracji zwykle składa się z głównej funkcji i kilku mniejszych elementów, które mają być wdrażane razem. Przeprowadź oddział integracyjny przez proces Twojego zespołu programistów (na przykład pytania i odpowiedzi oraz testy akceptacyjne). Wypchnij na nią drobne zatwierdzenia, aby zbliżyć się do stanu produkcyjnego, a następnie użyj gałęzi środowiska lub gałęzi wydania (omówione poniżej), aby przygotować ją do wdrożenia.

Należy pamiętać, że wkłady w gałęzi integracji muszą zostać scalone z następnym etapem wydania, zanim inna główna funkcja będzie mogła zostać scalona z gałęzią integracji — w przeciwnym razie mieszasz funkcje na różnych etapach ukończenia. To ograniczy twoją zdolność do uwolnienia tego, co jest gotowe.

Oddziały tematyczne

Zespoły będą chciały używać gałęzi tematów , jeśli ważne jest, aby utrzymać drzewa zmian w stanie, który można łatwo odczytać lub przywrócić poszczególne funkcje. Gałęzie tematów oznaczają, że zatwierdzenia mogą zostać nadpisane (przy użyciu wymuszenia) w celu oczyszczenia ich struktury i zostać zmniejszone do zatwierdzenia funkcji.

Gałęzie tematyczne są często własnością indywidualnego kontrybutora, ale mogą być również wyznaczoną przestrzenią, w której zespół może opracować funkcję. Inni współtwórcy wiedzą, że ten typ gałęzi może mieć przepisane drzewo zmian w dowolnym momencie i nie powinni próbować synchronizować z nim swoich lokalnych gałęzi.

Bez wykorzystywania gałęzi tematycznych w przepływie pracy Git jesteś ograniczony do trzymania się zatwierdzeń, które wypychasz do gałęzi zdalnej. Wymuszanie wypychania nowego drzewa zatwierdzeń do zdalnej gałęzi może rozzłościć innych współtwórców, którzy polegają na utrzymywanej integralności gałęzi, z którą się synchronizują.

Istnieje szansa, że ​​używasz tego wzorca przepływu pracy, nie zdając sobie z tego sprawy, ale warto mieć wspólny zestaw definicji między zespołami, aby wzmocnić stojące za nimi praktyki. Na przykład, konwencja poprzedzania nazwy gałęzi inicjałami twórcy gałęzi pomaga zasygnalizować, które gałęzie są tematyczne. Tak czy inaczej, decyzja o wewnętrznych konwencjach należy do Twojego zespołu.

NIE używaj gałęzi tematów w publicznych repozytoriach, powodujesz mnóstwo konfliktów u każdego, kto zsynchronizował swoje lokalne gałęzie z gałęzią tematu, która ma ponownie napisane drzewo commitów.

Widelec

Projekty open source rozwijają się dzięki tej funkcji wywodzącej się z Github. Widelec umożliwia opiekunom repozytorium wymuszoną bramę w celu wypychania bezpośrednio do gałęzi repozytorium pochodzenia, ale co ważniejsze, ułatwia współpracę. Łał!

Możesz znaleźć się w scenariuszu, w którym tworzenie forka prywatnego repozytorium również odpowiada Twoim potrzebom. Ustawienie repozytorium pochodzenia na tylko do odczytu dla współautorów repozytorium rozwidlenia i przewijanie z żądaniami ściągnięcia zapewnia te same korzyści, co społeczność open source. Zespoły z różnych organizacji mogą efektywnie pracować przy użyciu widelca, który może być platformą komunikacji i przestrzegania polityki projektowej.

Wzorzec przepływu pracy rozwidlenia zapewnia zespołom własną przestrzeń do pracy w dowolny sposób, do którego są przyzwyczajeni, z jednym punktem integracji między dwoma repozytoriami — żądaniem ściągnięcia. Nadmierna komunikacja jest niezbędna w opisie żądania ściągnięcia. Zespoły miały oddzielne strumienie komunikacji przed wysłaniem żądania ściągnięcia, a podkreślenie już podjętych decyzji przyspieszy proces przeglądu.

Oczywiście jedną z zalet przepływu pracy rozwidlenia jest to, że możesz kierować komentarze do współtwórców repozytorium pochodzenia, ponieważ uprawnienia spadają kaskadowo. Z punktu widzenia repozytorium pochodzenia masz kontrolę nad usuwaniem widełek, gdy nie są już potrzebne.

Upewnij się, że używasz narzędzia, które ułatwia rozwidlenie i ściąganie żądań, aby skorzystać z tego wzorca. Te narzędzia nie ograniczają się do Github: inne popularne opcje to Bitbucket i GitlLab. Istnieje jednak wiele innych usług hostingowych przepływu pracy Git, które będą miały te funkcje (lub podobne). Wybierz najlepszą dla siebie usługę.

NIE używaj rozwidlenia prywatnego repozytorium dla każdego członka zespołu. Liczne rozwidlone repozytoria mogą utrudniać współpracę wielu członków w tej samej gałęzi funkcji, a synchronizacja wszystkich tych repozytoriów może być podatna na błędy ze względu na samą liczbę ruchomych części. Projekty typu open source mają podstawowych członków zespołu z dostępem do wypychania do repozytorium pochodzenia, co zmniejsza to obciążenie.

Klon

Powszechną strategią outsourcingu jest posiadanie „miejsc” wkładu w projekt, który może być obsadzony przez wielu programistów. To do firmy outsourcingowej należy zarządzanie strumieniem zasobów w celu dostarczenia zakontraktowanych godzin. Problemy, z którymi się borykają, to jak wdrożyć, szkolić i utrzymywać pulę swoich programistów dla projektów każdego klienta.

Korzystanie z klona repozytorium projektu stanowi wyizolowany grunt do szkolenia i komunikacji dla zewnętrznego zespołu, aby zarządzać swoim wkładem, egzekwować zasady i korzystać z dzielenia się wiedzą — wszystko to pod czujnym okiem zespołu programistycznego klienta. Gdy wkład zostanie uznany za zgodny ze standardem i gotowy do głównego repozytorium, można go przenieść do jednej ze zdalnych gałęzi repozytoriów pochodzenia i zintegrować jak zwykle.

Niektóre projekty mają wysokie oczekiwania dotyczące przestrzegania ich konwencji kodowania i zdefiniowanych standardów przepływu pracy Git w celu wniesienia wkładu do ich repozytorium. Praca w tym środowisku może być zniechęcająca, dopóki nie nauczysz się podstaw, więc pracuj razem jako zespół, aby zoptymalizować czas obu stron.

NIE twórz hostowanej kopii repozytorium klienta bez jego zgody, ponieważ możesz złamać umowę, sprawdź z góry, czy ta praktyka przyniesie korzyści projektowi z klientem.

Zarządzanie wydaniami

Kroki między przejściem od współpracy do wydania rozpoczną się w różnych punktach procesu rozwoju dla każdego zespołu. Ogólnie rzecz biorąc, nie chcesz używać więcej niż jednego wzorca Git do zarządzania wydaniami. Chcesz mieć możliwie najprostszy przepływ pracy, który umożliwi Twojemu zespołowi skuteczne dostarczanie.

Oddziały środowiskowe

Twój proces tworzenia oprogramowania może być obsługiwany przez kilka środowisk, aby pomóc w zapewnieniu jakości przed wdrożeniem do produkcji. Gałęzie środowiska naśladują etapy tego procesu: każdy etap odpowiada gałęzi, a wkłady przepływają przez nie rurociągiem.

Zespoły działające z tymi procesami często mają skonfigurowane środowiska aplikacji dla każdego etapu potoku, na przykład „QA”, „Staging” i „Produkcja”. W takich przypadkach infrastruktura ma wspierać personel, który jest odpowiedzialny za podpisanie funkcji lub wkładu w ich część tego, co oznacza gotowość produkcyjną (np. testowanie eksploracyjne, kontrola jakości, testowanie akceptacyjne), przed przeniesieniem ich do kolejnej osoby. scena. Daje im to własne miejsce do wdrażania, testowania i oceny pod kątem ich wymagań, dzięki przepływowi pracy Git, który rejestruje podróż przez tunel podpisywania.

Posiadanie oddziału na każdym etapie procesu jest w porządku dla małych zespołów, które mogą pracować nad wydaniem jako jednostka. Niestety, taki rurociąg może zbyt łatwo zawęzić gardło lub zbić się i pozostawić luki. Łączy proces Git z infrastrukturą, co może powodować problemy, gdy funkcja wymaga przyspieszenia, a oba procesy wymagają skalowania.

NIE używaj tego wzoru bez uprzedniego rozważenia długoterminowych korzyści innych wzorów.

Wydanie oddziałów

Zespół, który jako jednostka w kolejnych sprintach wypycha zbiór wkładów do swojej aplikacji produkcyjnej, może znaleźć korzystne dopasowanie gałęzi wydania .

Zbiór prawie „gotowych do produkcji” zatwierdzeń otrzymuje drobne poprawki błędów w gałęzi wydania. Użyj gałęzi integracji, aby połączyć i przetestować funkcje przed przeniesieniem drzewa zatwierdzenia do gałęzi wydania. Ogranicz odpowiedzialność za gałąź wydania do ostatecznego sprawdzenia przed wdrożeniem do aplikacji produkcyjnej.

Gałęzie wydania różnią się od gałęzi środowiskowych tym, że mają krótką żywotność. Gałęzie wydania są tworzone tylko wtedy, gdy są potrzebne, i niszczone po wdrożeniu drzewa zmian w środowisku produkcyjnym.

Staraj się nie dopuścić do łączenia rozgałęzień wydań z twoją mapą rozwoju oprogramowania. Ograniczenie się do przestrzegania wcześniej określonego planu opóźnia wdrażanie wersji do momentu, gdy wszystkie planowane funkcje będą gotowe do produkcji. Nieprzypisanie numeru wersji do planu przed utworzeniem gałęzi wydania może złagodzić tego typu opóźnienia, umożliwiając umieszczenie i wdrożenie funkcji gotowych do produkcji w gałęzi wydania.

Użyj konwencji nazewnictwa numerów wersji dla nazwy gałęzi wydania, aby jasno określić, która wersja repozytorium została wdrożona w środowisku produkcyjnym.

Wdróż gałąź master, a nie gałąź wydania. Aby zachęcić do wprowadzania drobnych poprawek w gałęziach wydania przed scaleniem z gałęzią master, użyj zaczepu Git na gałęzi master, aby wyzwolić po scaleniu, aby automatycznie wdrożyć zaktualizowane drzewo zatwierdzeń w środowisku produkcyjnym.

Zezwolenie na istnienie tylko jednej gałęzi wydania w danym momencie zapewnia uniknięcie narzutu związanego z utrzymywaniem wielu gałęzi wydania w synchronizacji ze sobą.

NIE używaj gałęzi wydania z wieloma zespołami pracującymi na tym samym repozytorium. Mimo że gałęzie wydań są krótkotrwałe, jeśli ostateczne sprawdzenie ich trwa zbyt długo, wstrzymuje to drugi zespół przed wydaniem. Zespół świnki wspierający się na gałęzi wydania innego zespołu prawdopodobnie wprowadzi błędy i spowoduje opóźnienia dla obu zespołów. Spójrz na poniższy wzór wydania z sygnaturą czasową, który sprawdza się lepiej w przypadku większej liczby i grup współtwórców.

Wydania ze znacznikiem czasu

Aplikacje z ograniczeniami infrastrukturalnymi często planują swoje wdrożenia w okresach niskiego natężenia ruchu. Jeśli Twój projekt ma do czynienia z regularnymi kolejkami funkcji gotowych do wdrożenia, możesz skorzystać na wydaniu ze znacznikiem czasu .

Wydanie ze znacznikiem czasu opiera się na procesie wdrażania, który automatycznie dodaje znacznik znacznika czasu do ostatniego zatwierdzenia w gałęzi master, która została wdrożona w środowisku produkcyjnym. Gałęzie tematów służą do przeprowadzania funkcji przez proces rozwoju przed scaleniem jej z gałęzią główną w oczekiwaniu na wdrożenie.

Znacznik sygnatury czasowej powinien zawierać rzeczywistą sygnaturę czasową i etykietę wskazującą, że reprezentuje wdrożenie, na przykład: deployed-201402121345 .

Dołączenie metadanych wdrożenia, w postaci znacznika czasu w drzewie zatwierdzeń gałęzi master, pomoże w debugowaniu regresji udostępnionych w aplikacji produkcyjnej. Osoba odpowiedzialna za poszukiwanie przyczyny problemu prawdopodobnie nie będzie wiedziała wiele o każdej linii wdrożonej w aplikacji produkcyjnej. Uruchomienie polecenia git diff na dwóch ostatnich tagach może szybko dać migawkę tego, jakie zatwierdzenia zostały ostatnio wdrożone i kim są autorzy zatwierdzeń, którzy mogą pomóc w rozwiązaniu problemu.

Gałęzie ze znacznikiem czasu to więcej niż wydaje się na powierzchni. Prosty mechanizm rejestrowania wdrażania funkcji umieszczonych w kolejce wymaga zaskakująco dobrego procesu, aby go napędzać. Proces ten można skalować i dobrze sprawdza się również w przypadku małego zespołu współpracowników.

Aby ten wzorzec przepływu pracy Git był naprawdę skuteczny, musi być zawsze wdrażalna gałąź główna. Może to oznaczać różne rzeczy dla twojego zespołu, ale zasadniczo wszystkie zatwierdzenia muszą przejść przez proces rozwoju twojego projektu, zanim trafią do gałęzi master.

Nowe commity lądujące na gałęzi master będą się pojawiać kilka razy dziennie. Jest to problem dla gałęzi tematycznych, które przeszły proces rozwoju i nie zostały w tym czasie zsynchronizowane z gałęzią główną. Niestety taki scenariusz może wprowadzić regresje do gałęzi master, gdy konflikty scalania są niewłaściwie rozwiązywane.

Jeśli pojawią się konflikty scalania między gałęzią tematyczną a gałęzią master, ryzyko wprowadzenia nowego błędu powinno zostać omówione z zespołem przed aktualizacją zdalnej gałęzi master. Jeśli istnieje jakakolwiek wątpliwość, że może wystąpić regresja, gałąź tematu może zostać ponownie poddana procesowi zapewniania jakości z rozwiązaniem konfliktów scalania.

Aby zredukować błędy integracji, programiści pracujący nad powiązanymi częściami repozytorium mogą współpracować nad tym, kiedy najlepiej scalić i zsynchronizować swoje gałęzie tematyczne z gałęzią główną. Gałęzie integracji dobrze sprawdzają się również w rozwiązywaniu konfliktów z powiązanych gałęzi tematycznych — należy je poddać procesowi testowania przed połączeniem z kolejką oczekującej na wdrożenie gałęzi głównej.

Projekty rozwoju oprogramowania z wieloma współtwórcami muszą radzić sobie z procesami współpracy i zarządzania wydaniami z praktycznym i wydajnym podejściem. Dodatkowe metadane w drzewie zatwierdzeń, które uzyskujemy dzięki wykorzystaniu wydań ze znacznikami czasu, są wskaźnikiem przewidywania zespołów, które przygotowują się do reagowania na problemy produkcyjne.

Wersja oddziału

Jeśli masz repozytorium, które nie tylko uruchamiasz w środowisku produkcyjnym, ale które inni używają do własnych hostowanych aplikacji, użycie gałęzi wersji może dać Twojemu zespołowi platformę do obsługi użytkowników, którzy nie mogą lub nie mogą pozostać na krawędzi rozwoju Twojej aplikacji .

Repozytorium korzystające z gałęzi wersji będzie miało jedną gałąź na podrzędną wersję aplikacji. Wersje główne, pomocnicze i poprawki są wyjaśnione w dokumentacji wersjonowania semantycznego. Gałęzie wersji zazwyczaj są zgodne z konwencją nazewnictwa i zawierają słowo „stable” i usuwają numer poprawki z wersji aplikacji: np. 2-3-stable , aby ich cel i niezawodność były oczywiste dla użytkowników końcowych.

Tagi Git mogą być stosowane aż do numeru wersji poprawki aplikacji, ale gałęzie wersji nie są tak szczegółowe. Gałąź wersji zawsze będzie wskazywać na najbardziej stabilne zatwierdzenie dla obsługiwanej wersji pomocniczej.

Kiedy pojawią się poprawki bezpieczeństwa lub potrzeba backportu funkcjonalności, zbierz zatwierdzenia niezbędne do pracy ze starszymi wersjami aplikacji, które obsługujesz, i prześlij je odpowiednio do gałęzi wersji.

NIE używaj gałęzi wersji, chyba że obsługujesz więcej niż jedną wersję swojego repozytorium.

Streszczenie

Gdy Twój zespół zmienia wielkość lub Twój projekt rozwija swoje procesy poprzez ciągłą ocenę, nie pomiń również oceny procesu Git. Użyj wzorców z tego samouczka jako punktu wyjścia, aby poprowadzić Cię na ścieżce prawości przepływu pracy w Git.

Wzorzec przedstawiony w tym przewodniku może pomóc w uzbrajaniu się w przewidywania w dostosowywaniu rozproszonego systemu kontroli wersji do pracy dla Ciebie. Jeśli chcesz przeczytać o przepływach pracy Git, koniecznie sprawdź Gitflow, Github Flow i, co najważniejsze, niesamowitą dokumentację git-scm!