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

Azure DevOps Services | Azure DevOps Server 2022 r. — Azure DevOps Server 2019 | TFS 2018

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 koniecznością 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 tworzenie kodu.

Poniższe strategie rozgałęziania są oparte na sposobie używania usługi Git tutaj w firmie Microsoft. Aby uzyskać więcej informacji, zobacz How we use Git at Microsoft (Jak używamy usługi Git w firmie Microsoft).

Zachowaj prostą strategię gałęzi

Zachowaj prostą strategię gałęzi. Skompiluj swoją 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 wysoką jakość, aktualną gałąź główną.

Strategia, która rozszerza te pojęcia i unika sprzeczności, spowoduje przepływ pracy kontroli wersji dla twojego 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łęzi głównej. 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.

obraz podstawowego przepływu pracy rozgałęziania

Tworzenie gałęzi funkcji dla wszystkich zmian sprawia, że przeglądanie historii jest proste. Spójrz na zatwierdzenia wykonane 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 Wymagaj folderów gałęzi.

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

Dowiedz się więcej na temat używania flag funkcji w kodzie.

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

Przegląd, który odbywa się 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 do gałęzi głównej bez żądania ściągnięcia.

Przeglądy żądań ściągnięcia zajmują trochę czasu. Twój zespół powinien zgodzić się na to, czego oczekuje się od twórców i recenzentów żądań ściągnięcia. Rozdystrybuj 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, przełącz żą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ółdzielone przez zespół.
  • Podaj wystarczającą ilość szczegółów w opisie, aby szybko przyspieszyć wprowadzanie zmian przez recenzentów.
  • Dołącz kompilację lub połączoną wersję zmian uruchomionych w środowisku przygotowanym przy użyciu żądania ściągnięcia. Inne osoby mogą łatwo przetestować zmiany.

Zachowaj wysoką jakość, aktualną gałąź główną

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ół zaczęł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 do ukończenia żądania ściągnięcia. Kod scalony z gałęzią główną powinien być czysty.

Porada

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 wydania. 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, aby przestać obsługiwać określoną wersję.

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.

obraz przepływów pracy gałęzi wydania

Port zmienia się z powrotem do gałęzi głównej

Upewnij się, że poprawki lądują zarówno w gałęzi wydania, jak i w gałęzi głównej. Jednym z rozwiązań jest wprowadzenie poprawek w gałęzi wydania, a następnie wprowadzenie zmian do gałęzi głównej, aby zapobiec regresji w kodzie. Innym podejściem (a jednym z pracowników zespołu 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 wybierania 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 funkcji z gałęzią główną może spowodować przeniesienie zmian specyficznych dla wersji, 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ą, aby przełożyć zmiany.
  2. Cherry-pick 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.

Zaktualizowane przepływy pracy gałęzi wydania.

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 przepływy pracy rozgałęziania 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żnych. Tagi wprowadzają dodatkowe kroki w przepływie pracy, które nie są konieczne, jeśli używasz gałęzi dla wydań.

Tagi są zachowywane i wypychane oddzielnie od zatwierdzeń. Członkowie zespołu mogą łatwo przegapić tagowanie zatwierdzenia, a następnie muszą wrócić do historii, aby naprawić tag. Możesz również zapomnieć o dodatkowym kroku, aby wypchnąć tag, 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 wydań. Twój zespół nie musi przyjąć żadnego nowego procesu kontroli wersji innej 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 wydań. Utwórz jasną konwencję nazewnictwa, taką jak wdrażanie/test wydajnościowy, i traktuj gałęzie środowiska, takie jak gałęzie wydania. Twój zespół powinien zgodzić się na proces aktualizowania gałęzi wdrożenia 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.

Filmy wideo