Rozwiązywanie konfliktów scalania
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Visual Studio 2019 | Visual Studio 2022
Gdy scalasz lub robisz rebase, informujesz Git o zintegrowaniu zmian dokonanych w jednej gałęzi ze zmianami dokonanymi w innej gałęzi. Często usługa Git automatycznie wykonuje scalanie lub ponowne bazy danych bez twojej pomocy. Jeśli jednak usługa Git wykryje, że zmiana w jednej gałęzi powoduje konflikt ze zmianą wprowadzoną w innym, spowoduje to rozwiązanie konfliktu. Konflikt scalania może wystąpić, gdy scalone gałęzie edytują ten sam wiersz pliku inaczej lub gdy jedna gałąź modyfikuje plik, a inna gałąź je usuwa. Proces rozwiązywania konfliktów jest stosowany zarówno przy scalaniu w Git, jak i przy operacji rebase.
Konflikty scalania można rozwiązać w programie Visual Studio lub za pomocą wiersza polecenia i dowolnego edytora tekstów.
Aby zapoznać się z omówieniem przepływu pracy usługi Git, zobacz Samouczek usługi Azure Repos Git.
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. |
Zrozumienie konfliktów scalania
Scalanie lub przemieszczanie w Git integruje zatwierdzenia z gałęzi źródłowej z bieżącą gałęzią lokalną (gałąź docelowa). Git merge wykonuje albo przesunięcie do przodu, albo scalanie bez przesunięcia do przodu. Scalanie bez fast-forward jest również znane jako trójdrożne scalanie lub prawdziwe scalanie. Git rebase to inny typ scalania. Te typy scalania przedstawiono na poniższym diagramie.
W przypadku scalania Git, jeśli końcówka gałęzi docelowej znajduje się w gałęzi źródłowej, domyślnym typem scalania będzie scalanie w przód. W przeciwnym razie domyślnym typem scalania będzie scalanie bez przesuwania do przodu.
Szybkie scalanie nie może mieć konfliktu, ponieważ Git nie zastosuje szybkiego scalania, jeśli końcówka gałęzi docelowej odbiegła od gałęzi źródłowej. Domyślnie usługa Git używa szybkiego scalania zawsze, gdy jest to możliwe. Na przykład, Git zastosuje szybkie scalanie w lokalnej gałęzi, którą aktualizujesz tylko poprzez pobieranie z jej zdalnego odpowiednika.
Scalanie bez szybkiego przekazywania generuje nowy "commit scalający" w gałęzi docelowej, który integruje zmiany gałęzi źródłowej ze zmianami w gałęzi docelowej. Odpowiednie zmiany są wprowadzane po ostatnim zatwierdzeniu, które jest wspólne dla obu gałęzi. Na powyższym diagramie zatwierdzenie C jest ostatnim wspólnym zatwierdzeniem w obu gałęziach. Jeśli jakakolwiek zmiana gałęzi źródłowej powoduje konflikt z dowolną zmianą gałęzi docelowej, usługa Git wyświetli monit o rozwiązanie konfliktu scalania. Zatwierdzenie scalania (L) zawiera zmiany zintegrowanej gałęzi źródłowej i gałęzi docelowej. Porady dotyczące gałęzi źródłowej i docelowej (K i E) są elementami nadrzędnymi zatwierdzenia scalania. W historii zatwierdzania gałęzizatwierdzenie scalania jest przydatnym znacznikiem operacji scalania i wyraźnie pokazuje, które gałęzie zostały scalone.
Usługa Git rebase ponownie sekwencjonuje historię zatwierdzeń gałęzi docelowej, tak aby zawierała wszystkie zatwierdzenia gałęzi źródłowej, a następnie wszystkie zatwierdzenia gałęzi docelowej od ostatniego wspólnego zatwierdzenia. Na diagramie powyżej komit C jest ostatnim wspólnym komitem w obu gałęziach. Innym sposobem wyświetlenia jest to, że rebase odtwarza zmiany w gałęzi docelowej na początku historii gałęzi źródłowej. Jeśli jakakolwiek zmiana gałęzi źródłowej powoduje konflikt z dowolną zmianą gałęzi docelowej, usługa Git wyświetli monit o rozwiązanie konfliktu scalania. Podobnie jak w przypadku szybkiego scalania, baza rebase nie tworzy zatwierdzenia scalania. Zauważalnie, rebase zmienia sekwencję zatwierdzeń na istniejącej gałęzi docelowej, czego nie robią inne strategie scalania. Na powyższym diagramie zatwierdzenie K zawiera te same zmiany co K, ale ma nowy identyfikator zatwierdzenia, ponieważ łączy się z powrotem z zatwierdzeniem E zamiast C.
Procesy Git scalania i ponownego bazowania modyfikują tylko gałąź docelową — gałąź źródłowa pozostaje niezmieniona. W przypadku napotkania jednego lub większej liczby konfliktów scalania należy je rozwiązać, aby ukończyć scalanie lub bazę danych. Możesz też anulować operację scalania/bazy danych i zwrócić gałąź docelową do poprzedniego stanu.
Aby uzyskać więcej informacji na temat opcji scalania i strategii, zobacz podręcznik Git i strategie scalania Git.
Kiedy należy rozwiązać konflikty scalania
Git merge i Git rebase są szeroko używane w przepływie pracyusługi Git. Podczas pracy nad lokalną funkcją lub gałęzią poprawki usterek często zdarza się:
- Zachowaj lokalną gałąź
mainbieżącą z jego zdalnym odpowiednikiem, okresowo ściągając w celu pobierania i scalania zatwierdzeń zdalnych. - Zintegruj aktualizacje lokalnej gałęzi
mainz lokalną gałęzią funkcjonalności przy użyciu rebase lub scalania. - Wykonaj kopię zapasową pracy w lokalnej gałęzi funkcji, wypychając ją do odpowiedniej gałęzi zdalnej.
- Po ukończeniu funkcji utwórz pull request , aby scalić zdalną gałąź funkcjonalności z zdalną gałęzią
main.
Często integrując zmiany wprowadzone zdalnie w lokalnym repozytorium, możesz być na bieżąco ze zmianami dokonanymi przez innych i szybko rozwiązywać wszystkie konflikty scalania.
Rozwiązywanie konfliktów scalania
Proces rozwiązywania konfliktów scalania ma zastosowanie zarówno do scalania Git, jak i rebase Git. Chociaż w poniższych krokach opisano sposób rozwiązywania konfliktów podczas scalania, podobnie można rozwiązywać konflikty podczas operacji rebase.
Wskazówka
Jeśli gałąź źródłowa jest gałęzią śledzenia zdalnego, upewnij się, że gałąź jest up-to-date, uruchamiając pobierania git przed scaleniem. Możesz też uruchomić polecenie Git pull , które łączy pobieranie Git z scalaniem Git.
- Visual Studio 2022
- Visual Studio 2019 — menu Git
- Visual Studio 2019 — Team Explorer
- Wiersz polecenia Git
Program Visual Studio 2022 zapewnia środowisko kontroli wersji Git przy użyciu menu Git, Zmian Git oraz menu kontekstowych w Eksploratorze Rozwiązań. Program Visual Studio 2019 w wersji 16.8 oferuje również interfejs użytkownika narzędzia Team Explorer Git. Aby uzyskać więcej informacji, zobacz kartę Visual Studio 2019 — Team Explorer .
W okienku Gałęzie okna repozytorium Git wyewidencjonuj gałąź docelową. Następnie kliknij prawym przyciskiem myszy gałąź źródłową i wybierz Scal <gałąź źródłową> do <gałęzi docelowej>.
Program Visual Studio powiadomi Cię, jeśli narzędzie Git wstrzymało scalanie z powodu konfliktów. W takim przypadku można rozwiązać konflikty lub anulować scalanie i powrócić do stanu przed scalenia. Sekcja Niezmergowane zmiany w oknie Git Changes zawiera listę plików z konfliktami scalania. W przypadku pliku z konfliktami scalania w jego zawartości kliknij dwukrotnie plik, aby otworzyć go w edytorze scalania.
W edytorze scalania okienko Przychodzące zawiera wersję pliku gałęzi źródłowej, okienko Current zawiera docelową wersję pliku gałęzi, a okienko Result zawiera wynikowy plik scalania. Aby zastosować określone zmiany gałęzi źródłowej lub docelowej, zaznacz pole wyboru obok wierszy powodujących konflikt, które chcesz zachować. Możesz również bezpośrednio edytować plik scalania w okienku Wynik. Wybierz pozycję Zaakceptuj scalanie po rozwiązaniu wszystkich konfliktów scalania w bieżącym pliku. Powtórz ten krok dla każdego pliku z konfliktami zawartości.
W przypadku pliku, który został edytowany w jednej gałęzi i usunięty w drugiej, kliknij prawym przyciskiem myszy plik i wybierz odpowiednią akcję gałęzi.
W oknie Git Changes (Zmiany usługi Git) wprowadź komunikat zatwierdzenia i wybierz zatwierdzenie przygotowane, aby ukończyć scalanie — po rozwiązaniu wszystkich konfliktów scalania dla wszystkich plików.
