Adopt a Git branching strategy (Stosowanie strategii rozgałęziania systemu Git)

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Rozproszone systemy kontroli wersji, takie jak Git, zapewniają elastyczność w sposobie używania kontroli wersji do udostępniania kodu i zarządzania nim. Twój zespół powinien znaleźć równowagę między tą elastycznością a potrzebą współpracy i udostępniania kodu w spójny sposób.

Członkowie zespołu publikują, udostępniają, przeglądają i iterują zmiany kodu za pośrednictwem gałęzi git udostępnionych innym osobom. Przyjęcie strategii rozgałęziania dla zespołu. Możesz współpracować lepiej i poświęcać mniej czasu na zarządzanie kontrolą wersji i więcej czasu na opracowywanie kodu.

Poniższe strategie rozgałęziania są oparte na sposobie korzystania z usługi Git tutaj w firmie Microsoft. Aby uzyskać więcej informacji, zobacz Jak używamy usługi Git w firmie Microsoft.

Zachowaj prostą strategię gałęzi

Zachowaj prostą strategię gałęzi. Skompiluj strategię na podstawie tych trzech pojęć:

• Użyj gałęzi funkcji dla wszystkich nowych funkcji i poprawek błędów.
• Scal gałęzie funkcji z gałęzią główną przy użyciu żądań ściągnięcia.
• Zachowaj aktualną gałąź główną o wysokiej jakości.

Strategia, która rozszerza te koncepcje i unika sprzeczności, spowoduje przepływ pracy kontroli wersji dla zespołu, który jest spójny i łatwy do naśladowania.

Używanie gałęzi funkcji do pracy

Opracowywanie funkcji i naprawianie usterek w gałęziach funkcji opartych na gałęziach głównych. Te gałęzie są również nazywane gałęziami tematów. Gałęzie funkcji izolować pracę w toku od ukończonej pracy w gałęzi głównej. Gałęzie usługi Git są niedrogie do tworzenia i konserwacji. Nawet małe poprawki i zmiany powinny mieć własną gałąź funkcji.

Tworzenie gałęzi funkcji dla wszystkich zmian sprawia, że przeglądanie historii jest proste. Przyjrzyj się zatwierdzeń wykonanym w gałęzi i przyjrzyj się żądaniu ściągnięcia, które scaliło gałąź.

Nazwij gałęzie funkcji według konwencji

Użyj spójnej konwencji nazewnictwa dla gałęzi funkcji, aby zidentyfikować pracę wykonaną w gałęzi. Możesz również uwzględnić inne informacje w nazwie gałęzi, takie jak osoba, która utworzyła gałąź.

Niektóre sugestie dotyczące nazewnictwa gałęzi funkcji:

• użytkownicy/nazwa użytkownika/opis
• users/username/workitem
• usterka/opis
• feature/feature-name
• feature/feature-area/feature-name
• poprawka/opis

Uwaga

Aby uzyskać informacje na temat ustawiania zasad wymuszania strategii nazewnictwa gałęzi, zobacz Require branch folders (Wymagaj folderów gałęzi).

Używanie flag funkcji do zarządzania długotrwałymi gałęziami

Dowiedz się więcej o korzystaniu z flag funkcji w kodzie.

Przeglądanie i scalanie kodu z żądaniami ściągnięcia

Przegląd wykonywany w żądaniu ściągnięcia ma kluczowe znaczenie dla poprawy jakości kodu. Scalanie gałęzi tylko za pośrednictwem żądań ściągnięcia, które przechodzą proces przeglądu. Unikaj scalania gałęzi z gałęzią główną bez żądania ściągnięcia.

Ukończenie przeglądów w żądaniach ściągnięcia zajmuje trochę czasu. Twój zespół powinien uzgodnić oczekiwania twórców żądań ściągnięcia i recenzentów. Rozpowszechnij obowiązki recenzenta, aby dzielić się pomysłami w zespole i rozpowszechniać wiedzę na temat bazy kodu.

Niektóre sugestie dotyczące pomyślnych żądań ściągnięcia:

• Dwóch recenzentów jest optymalną liczbą opartą na badaniach.
• Jeśli Twój zespół ma już proces przeglądu kodu, przeprowadź żądania ściągnięcia do tego, co już robisz.
• Zadbaj o przypisanie tych samych recenzentów do dużej liczby żądań ściągnięcia. Żądania ściągnięcia działają lepiej, gdy obowiązki recenzenta są współużytkowane przez zespół.
• Podaj wystarczająco dużo szczegółów w opisie, aby szybko wprowadzić recenzentów, aby przyspieszyć wprowadzanie zmian.
• Dołącz kompilację lub połączoną wersję zmian uruchomionych w środowisku przygotowanym przy użyciu żądania ściągnięcia. Inni mogą łatwo przetestować zmiany.

Utrzymywanie wysokiej jakości, aktualnej gałęzi głównej

Kod w gałęzi głównej powinien przechodzić testy, kompilować w sposób czysty i zawsze być aktualny. Gałąź główna wymaga tych cech, aby gałęzie funkcji utworzone przez zespół zaczynały się od znanej dobrej wersji kodu.

Skonfiguruj zasady gałęzi dla gałęzi głównej, które:

• Wymaga żądania ściągnięcia do scalania kodu. Takie podejście uniemożliwia bezpośrednie wypychanie do gałęzi głównej i zapewnia dyskusję na temat proponowanych zmian.
• Automatycznie dodaje recenzentów po utworzeniu żądania ściągnięcia. Dodani członkowie zespołu przejrzyj kod i skomentują zmiany w żądaniu ściągnięcia.
• Wymaga pomyślnej kompilacji w celu ukończenia żądania ściągnięcia. Kod scalony z gałęzią główną powinien być kompilowany w sposób czysty.

Napiwek

Potok kompilacji dla żądań ściągnięcia powinien być szybki do ukończenia, więc nie zakłóca procesu przeglądu.

Zarządzanie wydaniami

Użyj gałęzi wydania, aby koordynować i stabilizować zmiany w wydaniu kodu. Ta gałąź jest długotrwała i nie jest scalona z powrotem z gałęzią główną w żądaniu ściągnięcia, w przeciwieństwie do gałęzi funkcji. Utwórz dowolną liczbę gałęzi wydań. Należy pamiętać, że każda aktywna gałąź wydania reprezentuje inną wersję kodu potrzebnego do obsługi. Zablokuj gałęzie wydania, gdy wszystko będzie gotowe do zatrzymania obsługi określonej wersji.

Używanie gałęzi wydań

Utwórz gałąź wydania z gałęzi głównej, gdy zbliżasz się do wydania lub innego punktu kontrolnego, takiego jak koniec przebiegu. Nadaj tej gałęzi wyraźną nazwę kojarzącą ją z wydaniem, na przykład release/20.

Utwórz gałęzie, aby naprawić usterki z gałęzi wydania i scalić je z powrotem do gałęzi wydania w żądaniu ściągnięcia.

Port zmienia się z powrotem na gałąź główną

Upewnij się, że naprawiono ziemię zarówno w gałęzi wydania, jak i w gałęzi głównej. Jednym z podejść jest wprowadzenie poprawek w gałęzi wydania, a następnie wprowadzenie zmian w gałęzi głównej, aby zapobiec regresji w kodzie. Innym podejściem (i jednym z zatrudnionych przez zespół usługi Azure DevOps) jest zawsze wprowadzanie zmian w linii głównej, a następnie przenoszenie ich do gałęzi wydania. Więcej informacji na temat naszej strategii przepływu wydania można przeczytać.

W tym temacie omówimy wprowadzanie zmian w gałęzi wydania i przenoszenie ich do linii głównej. Użyj wyboru wiśni zamiast scalania, aby mieć dokładną kontrolę nad tym, które zatwierdzenia są przenoszone z powrotem do gałęzi głównej. Scalanie gałęzi wydania z gałęzią główną może spowodować przeniesienie zmian specyficznych dla wydania, których nie chcesz w gałęzi głównej.

Zaktualizuj gałąź główną za pomocą zmiany wprowadzonej w gałęzi wydania, wykonując następujące kroki:

1. Utwórz nową gałąź funkcji poza gałęzią główną w celu przeniesienia zmian.
2. Wybierz zmiany z gałęzi wydania do nowej gałęzi funkcji.
3. Scal gałąź funkcji z powrotem do gałęzi głównej w drugim żądaniu ściągnięcia.

Ten przepływ pracy gałęzi wydania utrzymuje filary podstawowego przepływu pracy bez zmian: gałęzie funkcji, żądania ściągnięcia i silną gałąź główną, która zawsze ma najnowszą wersję kodu.

Dlaczego nie używać tagów dla wydań?

Inne rozgałęziania przepływów pracy używają tagów Usługi Git do oznaczania określonego zatwierdzenia jako wydania. Tagi są przydatne do oznaczania punktów w historii jako ważne. Tagi wprowadzają dodatkowe kroki w przepływie pracy, które nie są konieczne, jeśli używasz gałęzi dla wersji.

Tagi są zachowywane i wypychane oddzielnie od zatwierdzeń. Członkowie zespołu mogą łatwo przegapić tagowanie zatwierdzenia, a następnie wrócić do historii, aby naprawić tag. Możesz również zapomnieć o dodatkowym kroku wypychania tagu, pozostawiając następnego dewelopera działającego ze starszej wersji kodu podczas obsługi wydania.

Strategia gałęzi wydania rozszerza podstawowy przepływ pracy gałęzi funkcji w celu obsługi wersji. Twój zespół nie musi wdrażać żadnych nowych procesów kontroli wersji innych niż cherry-pick do zmian portów.

Zarządzanie wdrożeniami

Można obsługiwać wiele wdrożeń kodu w taki sam sposób, jak w przypadku wielu wersji. Utwórz wyraźną konwencję nazewnictwa, taką jak wdrażanie/test wydajnościowy, i traktuj gałęzie środowiska, takie jak gałęzie wydania. Twój zespół powinien uzgodnić proces aktualizowania gałęzi wdrażania przy użyciu kodu z gałęzi głównej. Poprawki błędów cherry-pick w gałęzi wdrażania z powrotem do gałęzi głównej. Wykonaj te same kroki co przenoszenie zmian z gałęzi wydania.

Wyjątkiem od tego zalecenia jest użycie formy ciągłego wdrażania. Użyj usługi Azure Pipelines podczas pracy z ciągłym wdrażaniem, aby podwyższyć poziom kompilacji z gałęzi głównej do celów wdrożenia.