Scalanie strategii i scalanie squasha
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Po zakończeniu żądania ściągnięcia scalasz 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 żądaniu ściągnięcia zapewniają dodatkowy kontekst zmian wprowadzonych w gałęzi tematu.
Historia zatwierdzeń w main gałęzi (lub innej gałęzi domyślnej) nie jest zgodna z linią prostą ze względu na powiązaną historię gałęzi tematu. Wraz ze wzrostem liczby gałęzi tematów w tym samym czasie rośnie liczba gałęzi, co sprawia, że domyślna historia gałęzi staje się coraz trudniejsza.
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.
Scalanie squasha
Scalanie typu squash to opcja scalania, która umożliwia skondensować historię tematów usługi Git podczas wykonywania żądania ściągnięcia. Zamiast każdego zatwierdzenia w gałęzi tematu dodawanej do historii gałęzi domyślnej scalanie typu squash dodaje wszystkie zmiany plików do pojedynczego nowego zatwierdzenia w gałęzi domyślnej. Zatwierdzenie scalania squasha nie zawiera odwołania do gałęzi tematu. Spowoduje to wygenerowanie nowego zatwierdzenia zawierającego wszystkie zmiany z gałęzi tematu. Ponadto zaleca się usunięcie gałęzi tematu, aby zapobiec nieporozumieniu.
Prostym sposobem myślenia o tym jest to, że scalanie squasha daje tylko zmiany pliku, a regularne scalanie zapewnia zmiany pliku i historię zatwierdzania.
Jak przydatne jest scalanie squasha?
Scalanie squasha zapewnia czyste i łatwe śledzenie domyślnych historii gałęzi bez konieczności wprowadzania żadnych zmian w przepływie pracy w zespole. Współautorzy gałęzi tematu pracują, jak chcą w gałęzi tematu, a domyślne gałęzie zachowują historię liniową za pomocą scalania typu squash. Historia zatwierdzeń gałęzi zaktualizowanej main za pomocą scalania typu squash ma 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 squasha kondensuje historię zmian w gałęzi domyślnej, dlatego ważne jest, aby pracować z zespołem, aby zdecydować, kiedy należy scalić scalanie typu squash lub kiedy chcesz zachować pełną historię zatwierdzeń gałęzi tematu. Podczas scalania squasha dobrym rozwiązaniem jest usunięcie gałęzi źródłowej. Usunięcie gałęzi źródłowej zapobiega nieporozumieniu, ponieważ sama gałąź tematu nie zawiera zatwierdzenia scalającego go z gałęzią domyślną.
Uzupełnianie żądań ściągnięcia za pomocą scalania squasha
Scalanie z ściągnięciem można wybrać podczas kończenia żądania ściągnięcia w usłudze Azure Repos.
Wybierz pozycję Zatwierdzenie squasha w obszarze Typ scalania w oknie dialogowym Zakończ żądanie ściągnięcia, aby scalić gałąź tematu.
Wiele baz scalania
Karta Pliki w żądaniu ściągnięcia wykrywa różnice w porównaniu z trzema stronami. Algorytm uwzględnia ostatnie zatwierdzenie w gałęzi docelowej, ostatnie zatwierdzenie w gałęzi źródłowej i ich wspólną bazę scalania (tj. najlepszy wspólny element 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 git merge-base --all feature master polecenie . Usługa Azure DevOps wykrywa istnienie wielu baz scalania dla każdego żądania ściągnięcia. Po ich wykryciu usługa Azure DevOps wyświetla komunikat "Wykryto wiele baz scalania. Wyświetlona lista zatwierdzeń może być niekompletna" dla żądania ściągnięcia. 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 wiele baz scalania nie jest główną przyczyną.
Następujące scenariusze są wykrywane przez usługę Azure DevOps jako wiele baz (bazy scalania są wskazywane przez liczbę 1 i 2):
- Scalania krzyżowe (nazywane również criss-cross) między różnymi gałęziami (raportowanych przez usługę Azure DevOps, a także
git merge-base)
---1---o---A
\ /
X
/ \
---2---o---o---B
- Scalanie jednej gałęzi z dwiema innymi gałęziami (zgłoszone przez usługę Azure DevOps, ale nie przez
git merge-baseto eliminuje scalanie base 2)
---1---o---o---o---A
\ /
\-------2
\ \
\---o---o---o---B
- Obsługa rewersji gałęzi głównej, np. zmiana zatwierdzenia scalania
* 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 nie intuicyjne i zawiłe manipulacje z reverts, cherry picks i scalania
Wiele wykrywania podstawowego scalania jest częścią świadomości zabezpieczeń. 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 bazami scalania, wystąpi wiele ostrzeżeń podstawowych scalania.
Aby uzyskać więcej informacji, zapoznaj się z oficjalną dokumentacją usługi Git.
Potencjalne zagrożenia bezpieczeństwa scalania z wielu baz
- Złośliwy użytkownik może nadużywać algorytmu interfejsu użytkownika w celu zatwierdzenia złośliwych zmian, które nie są obecne w żądaniu ściągnięcia.
- Jeśli zmiany proponowane w żądaniu ściągnięcia znajdują się już w gałęzi docelowej, są one wyświetlane na karcie Pliki , ale mogą nie wyzwalać zasad gałęzi, które są mapowane na zmiany folderów.
- Dwa zestawy zmian w tych samych plikach z wielu baz scalania mogą nie być obecne w żądaniu ściągnięcia. 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 resetowanie miękkie i skryte postęp przed ponownym łączeniem lub scalanie. Następnie możesz utworzyć nową gałąź lub ponownie utworzyć pustą gałąź i zastosować zmiany z jasnego punktu. 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 wielu problemów z bazą 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 bazami scalania pojawia 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ługotrwałe żądanie ściągnięcia, może to odtworzyć sytuację. Mimo że zasady kompilacji i testy są uruchomione, nie masz możliwości ukończenia żądania ściągnięcia. 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.