Łączenie strategii i scalanie zmian za pomocą squasha
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Po zakończeniu żądania ściągnięcianależy scalić gałąź tematu z gałęzią domyślną, zazwyczaj main. To scalanie powoduje dodanie zatwierdzeń gałęzi tematu do gałęzi głównej i utworzenie zatwierdzenia scalania w celu uzgodnienia konfliktów między gałęzią domyślną a gałęzią tematu. Komentarze i dyskusja w pull request dostarczają więcej kontekstu dla zmian wprowadzonych w gałęzi tematycznej.
Historia zatwierdzania w gałęzi main (lub innej gałęzi domyślnej) nie jest zgodna z linią prostą ze względu na powiązaną historię gałęzi tematu. W miarę jak projekt staje się większy, liczba gałęzi tematów, nad którymi pracuje się jednocześnie, rośnie, co sprawia, że śledzenie historii domyślnej gałęzi staje się coraz trudniejsze.
Gałąź domyślna to dokładna reprezentacja historii każdej gałęzi tematu, ale trudno jest użyć do odpowiadania na szersze pytania dotyczące programowania projektu.
Wymagania wstępne
| Kategoria | Wymagania |
|---|---|
| Dostęp do projektu | Członek projektu . |
| uprawnienia | — Wyświetlanie kodu w projektach prywatnych: co najmniej dostęp na poziomie Podstawowym. — Klonowanie lub współtworzenie kodu w prywatnych projektach: członkostwo w grupie zabezpieczeń Współautorzy lub odpowiednie uprawnienia w projekcie. — Ustaw uprawnienia gałęzi lub repozytorium: Zarządzanie uprawnieniami dla gałęzi lub repozytorium. - Zmień gałąź domyślną: Edytuj zasady uprawnienia dla repozytorium. — Zaimportuj repozytorium: członek grupy zabezpieczeń Administratorzy projektów lub uprawnienia na poziomie projektu Git Utwórz repozytorium ustawione na Dozwolone. Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień repozytorium Git. |
| Usługi | Repozytoria włączone. |
| Narzędzia | Opcjonalny. Użyj poleceń az repos: Azure DevOps CLI. |
Uwaga
W projektach publicznych użytkownicy z dostępem Stakeholder mają pełny dostęp do usługi Azure Repos, w tym wyświetlanie, klonowanie i współtworzenie kodu.
| Kategoria | Wymagania |
|---|---|
| Dostęp do projektu | Członek projektu . |
| uprawnienia | — Wyświetl kod: przynajmniej podstawowy dostęp. — Klonowanie lub współtworzenie kodu: członek grupy zabezpieczeń Współtwórców lub posiadający odpowiednie uprawnienia w projekcie. |
| Usługi | Repozytoria włączone. |
Scalanie z redukcją zmian
Scalanie typu squash to opcja scalania, która umożliwia skondensować historię gałęzi tematycznych w Git przy rozpatrywaniu pull request. Zamiast dodawać każde zatwierdzenie w gałęzi tematu do historii gałęzi domyślnej, scalanie typu squash dodaje wszystkie zmiany pliku do jednego nowego zatwierdzenia w gałęzi domyślnej. Zatwierdzenie scalania squash nie ma odwołania do gałęzi roboczej. Tworzy nowe zatwierdzenie zawierające wszystkie zmiany z gałęzi tematycznej. Zalecamy usunięcie gałęzi tematu, aby zapobiec nieporozumieniu.
Łatwo to zrozumieć, że scalanie typu squash daje tylko zmiany w plikach, a regularne scalanie daje zmiany w plikach i historię zatwierdzania.
W czym jest pomocne scalanie typu squash?
Scalanie typu squash pozwala utrzymać czystą i przejrzystą historię domyślnych gałęzi bez konieczności zmiany przepływu pracy zespołu. Współautorzy gałęzi tematu działają tak, jak chcą w gałęzi tematu, a domyślne gałęzie zachowują historię liniową przy użyciu scalania squasha. Historia zatwierdzeń gałęzi main zaktualizowana za pomocą scalania typu squash zawiera jedno zatwierdzenie dla każdej scalonej gałęzi. Możesz przejść przez tę historię, aby dowiedzieć się dokładnie, kiedy wykonano pracę.
Zagadnienia dotyczące scalania squasha
Scalanie za pomocą squasha kondensuje historię zmian w gałęzi domyślnej, dlatego ważne jest, aby ustalić z zespołem, kiedy zastosować scalanie za pomocą squasha, a kiedy zachować pełną historię zatwierdzeń w gałęzi tematycznej. Podczas scalania metodą squash, dobrym zwyczajem jest usunięcie gałęzi źródłowej. Usunięcie gałęzi źródłowej zapobiega nieporozumieniu, ponieważ gałąź tematyczna sama nie ma zatwierdzenia scalającego jej z gałęzią domyślną.
Uzupełnianie pull requestów za pomocą scalania typu squash
Możesz wybrać scalanie 'squash' podczas kończenia żądania wciągnięcia w usłudze Azure Repos.
Wybierz Squash commit w sekcji Rodzaj scalania w oknie dialogowym Zakończ żądanie ściągnięcia, aby złączyć gałąź tematyczną poprzez squash.
Wiele baz scalania
Karta Files w żądaniu ściągnięcia wykrywa różnice (diffs) w porównaniu trójstronnym. Algorytm uwzględnia ostatnie zatwierdzenie w gałęzi docelowej, ostatnie zatwierdzenie w gałęzi źródłowej i ich typową bazę scalania, na przykład najlepszy wspólny obiekt nadrzędny. Algorytm jest szybką, opłacalną i niezawodną metodą wykrywania zmian. Niestety, w niektórych przypadkach istnieje więcej niż jedna prawdziwa baza. W większości repozytoriów ta sytuacja jest rzadka, ale w dużych repozytoriach z wieloma aktywnymi użytkownikami może to być powszechne. Możesz sprawdzić ręcznie, czy istnieje wiele baz scalania między gałęziami. W tym celu uruchom polecenie git merge-base --all feature master. Usługa Azure DevOps wykrywa obecność wielu baz scalania dla każdego żądania scalającego. Po ich wykryciu usługa Azure DevOps wyświetla komunikat "Wykryto wiele baz scalania. Wyświetlona lista zatwierdzeń może być niekompletna dla PR. Podczas gdy usługa Azure DevOps uruchamia wykrywanie wielu baz scalania, nie sprawdza, czy potencjalna baza scalania została już scalona, czy nie. Takie sprawdzenie jest wykonywane przez git merge-base. Dlatego usługa Azure DevOps może wyświetlać komunikat nawet wtedy, gdy git merge-base raportuje tylko jedną bazę scalania.
Uwaga
W przypadku utraty zmian podczas przeglądu żądania ściągnięcia upewnij się, że istnienie wielu baz scalania nie jest przyczyną problemu.
Następujące przykładowe scenariusze są wykrywane przez usługę Azure DevOps jako wiele baz, z bazami scalania wskazywanymi przez liczby jeden i dwa:
- Scalania krzyżowe (znane również jako przeplatanka) między różnymi gałęziami (zgłaszane przez Azure DevOps i
git merge-base)
---1---o---A
\ /
X
/ \
---2---o---o---B
- Scalanie jednej gałęzi z dwiema innymi gałęziami (zgłoszone przez Azure DevOps, ale nie przez
git merge-base, który eliminuje bazę scalania 2)
---1---o---o---o---A
\ /
\-------2
\ \
\---o---o---o---B
- Obsługa następstw cofnięcia gałęzi głównej, na przykład poprawienie zatwierdzenia scalającego
* 42bb2d2 (HEAD, A) Amended merge commit
|\
| | * 67c9bb8 (other) Merge branch 'A' into B
| | |\
| |/ /
|/| /
| |/
| * fa78e32 add second commit
* | 15845c9 add first commit
|/
* 6a52130 add init
- Aktywne ponowne używanie gałęzi funkcji
- Inne nieintuicyjne i zawiłe manipulacje z cofnięciami, wyborem zmian i scalaniami
Wykrywanie wielu baz scalania jest częścią świadomości bezpieczeństwa. Jeśli istnieje wiele baz scalania, algorytm różnic plików dla interfejsu użytkownika może nie wykrywać poprawnie zmian w plikach, w zależności od wybranej bazy scalania. Jeśli pliki w żądaniu ściągnięcia mają różne wersje między podstawami scalania, pojawi się ostrzeżenie o wielu podstawach scalania.
Aby uzyskać więcej informacji, przejrzyj oficjalną dokumentację usługi Git.
Potencjalne zagrożenia bezpieczeństwa scalania z wielu baz
- Złośliwy użytkownik może nadużywać algorytmu w interfejsie użytkownika, aby wprowadzać złośliwe zmiany, które nie są obecne w żądaniu ściągnięcia.
- Jeśli zmiany proponowane w pull request znajdują się już w gałęzi docelowej, są wyświetlane na karcie Pliki, ale mogą nie wyzwalać zasad gałęzi powiązanych ze zmianami w folderach.
- Dwa zestawy zmian w tych samych plikach z wielu baz scalania mogą nie być obecne w pull request. Ten przypadek może stworzyć zdradliwe luki logiki.
Jak rozwiązać problem z wieloma bazami scalania
Posiadanie wielu baz scalania niekoniecznie jest złe, ale należy dokładnie sprawdzić, czy wszystko jest w porządku. Aby pozbyć się wielu baz scalania, należy powiązać gałęzie z jednym wspólnym elementem nadrzędnym przez ponowne łączenie gałęzi w lokalizacji docelowej lub scalanie elementu docelowego z gałęzią. Te akcje pozbywają się komunikatu ostrzegawczego i pomagają sprawdzić, czy rzeczywiste zmiany są w porządku.
Jednym z podejść jest miękkie resetowanie i zachowanie postępu przed ponownym łączeniem lub scalaniem. Następnie możesz utworzyć nową gałąź lub zrebazować pustą gałąź i zastosować zmiany od wyraźnego punktu wyjścia. Ten proces może wymagać wymuszonego wypychania do zdalnego, jeśli zmiany już istnieją.
Jak uniknąć problemu z wieloma bazami scalania
Poniżej przedstawiono ogólne porady dotyczące unikania problemu z wieloma bazami scalania:
- Podczas przygotowywania żądania ściągnięcia utwórz gałęzie funkcji na podstawie najnowszych wersji głównej lub gałęzi wydania.
- Unikaj tworzenia gałęzi, które nie pochodzą bezpośrednio ze stabilnych gałęzi repozytorium, chyba że jest to wymagane.
Co zrobić, jeśli problem z wieloma podstawami scalania pojawi się ponownie
W dużych repozytoriach z wieloma aktywnymi współautorami ten problem może być szczególnie niewygodny. Nawet jeśli pozbysz się wielu baz za pośrednictwem scalania, sytuacja może pojawić się ponownie. Jeśli ktoś zamknie długo otwarty pull request, może to odtworzyć sytuację. Mimo że polityki budowania i testy są uruchomione, nie masz możliwości ukończenia pull requestu. Zresetowanie i uruchomienie nowej gałęzi może pomóc. Jeśli nic się nie zmieni, zmiany są prawdopodobnie jasne, nawet jeśli sytuacja się powtórzy.