Stosowanie zmian za pomocą zmieniania bazy

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

Visual Studio 2019 | Visual Studio 2022

Usługa Git automatycznie utrzymuje historię programowania w gałęzi , łącząc każde nowe zatwierdzenie z jego poprzednikiem. Po scaleniu jednej gałęzi z inną historia może stać się mniej prosta. Na przykład scalanie bez szybkiego przekazywania łączy rozbieżne linie programowania, tworząc zatwierdzenie scalania z wieloma poprzednikami. Z drugiej strony baza danych Git łączy rozbieżne linie programowania bez tworzenia zatwierdzenia scalania, co powoduje prostszą historię zatwierdzeń, ale traci informacje o scalaniu. Wybór typu scalania może mieć wpływ na to, czy chcesz zachować rekord scalania, czy uprościć historię zatwierdzania.

W tym artykule omówiono, kiedy używać bazy rebase zamiast scalania bez szybkiego przekazywania, i przedstawiono procedury dla następujących zadań:

• Zmień bazę gałęzi lokalnej
• Wymusić wypchnięcie gałęzi lokalnej po rebase
• Interakcyjna ponowna baza danych do zatwierdzeń lokalnych zmiecenia lokalnego

Aby zapoznać się z omówieniem przepływu pracy usługi Git, zobacz Samouczek usługi Azure Repos Git.

Zmień bazę gałęzi lokalnej

Baza danych Git integruje zatwierdzenia z gałęzi źródłowej z bieżącą gałęzią lokalną (gałąź docelowa). Gałąź źródłowa pozostaje niezmieniona. Dla porównania baza danych Git i inne typy scalania są pokazane na poniższym diagramie.

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. Innym sposobem wyświetlenia jest to, że rebase odtwarza zmiany w gałęzi docelowej na początku historii gałęzi źródłowej. W szczególności baza danych Git zmienia sekwencję istniejących zatwierdzeń gałęzi docelowej, co nie jest w przypadku innych strategii 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.

Podczas ponownej bazy, jeśli zmiana gałęzi źródłowej powoduje konflikt ze zmianą gałęzi docelowej, usługa Git wyświetli monit o rozwiązanie konfliktu scalania. Konflikty scalania można rozwiązać podczas ponownej bazy w taki sam sposób, jak rozwiązywanie konfliktów scalania podczas scalania.

Ponowne bazy danych a nie szybkie scalanie

Ponowne tworzenie repozytorium Git powoduje prostszą, ale mniej dokładną historię zatwierdzeń niż scalanie bez szybkiego przesyłania dalej , inaczej znane jako trzykierunkowe lub prawdziwe scalanie. Jeśli chcesz zarejestrować rekord scalania w historii zatwierdzeń, użyj scalania bez szybkiego przekazywania.

Jeśli jesteś jedyną osobą pracującą nad funkcją lub gałęzią poprawki usterek, rozważ użycie bazy danych w celu okresowego zintegrowania z nią ostatniej main gałęzi. Ta strategia pomaga zapewnić, że będziesz mieć świadomość ostatnich prac innych osób i szybko rozwiąż wszelkie pojawiające się konflikty scalania. Po ponownym utworzeniu nowej funkcji należy zaimplementować najnowszą main pracę gałęzi, która pomaga zachować liniową historię zatwierdzeń.

Aby uzyskać więcej informacji na temat bazy danych Git i czasu jej używania, zobacz Rebase vs merge.

Rebase and force-push guidelines (Ponowne bazy danych i wymuszania wypychania)

Jeśli bazujesz ponownie gałąź lokalną, która została wcześniej wypchnięta, a następnie ponownie uruchom domyślne polecenie wypychania Git, wypychanie zakończy się niepowodzeniem. Domyślne polecenie wypychania Git stosuje scalanie szybkie do przodu, aby zintegrować gałąź lokalną z gałęzią zdalną. To polecenie zakończy się niepowodzeniem po rebase, ponieważ baza rebase zmienia sekwencję istniejących zatwierdzeń w lokalnej gałęzi docelowej, więc nie jest już zgodna z historią swojego odpowiednika zdalnego. W tym scenariuszu wymuszone wypchnięcie powiedzie się — zastępując gałąź zdalną.

Baza danych Git i wymuszanie wypychania są zaawansowanymi narzędziami, ale pamiętaj o tych wytycznych podczas podejmowania decyzji, czy ich używać:

• Nie bazuj na lokalnej gałęzi, która została wypchnięta i udostępniona innym osobom, chyba że masz pewność, że nikt nie korzysta z udostępnionej gałęzi. Po zmianie bazy gałąź lokalna nie będzie już zgodna z historią swojego odpowiednika zdalnego.
• Nie wymuszaj wypychania do zdalnej gałęzi, która jest używana przez inne osoby, ponieważ ich lokalna wersja gałęzi zdalnej nie będzie już zgodna ze zaktualizowaną historią gałęzi zdalnej.
• Twój zespół powinien uzgodnić scenariusze użycia dla ponownej bazy danych i wymuszenia wypychania.

Napiwek

W przypadku wspólnego procesu przeglądu użyj żądania ściągnięcia, aby scalić nową pracę z domyślną gałęzią repozytorium zdalnego.

Jak przebazować bazę danych

Visual Studio 2022

Program Visual Studio 2022 zapewnia środowisko kontroli wersji usługi Git przy użyciu menu Git, zmian git i menu kontekstowych w Eksplorator 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 .

1. Wybierz pozycję Git Manage Branches (Zarządzanie gałęziami usługi Git>), aby otworzyć okno Repozytorium Git.

   

2. W oknie Repozytorium Git kliknij prawym przyciskiem myszy gałąź docelową i wybierz polecenie Wyewidencjonuj.

   

3. Kliknij prawym przyciskiem myszy gałąź źródłową i wybierz polecenie Zmień bazę <docelową-gałąź na <gałąź>> źródłową.

   

4. Program Visual Studio wyświetli komunikat potwierdzający po pomyślnym ponownym zdaniu bazy danych.

   

   Jeśli baza bazy danych zostanie zatrzymana z powodu konfliktów scalania, program Visual Studio powiadomi Cię. Możesz rozwiązać konflikty lub anulować rebase i powrócić do stanu bazy wstępnej.

   

Visual Studio 2019 — menu Git

Program Visual Studio 2019 zapewnia środowisko kontroli wersji usługi Git przy użyciu menu Git, zmian git i menu kontekstowych w Eksplorator rozwiązań.

1. Wybierz pozycję Git Manage Branches (Zarządzanie gałęziami usługi Git>), aby otworzyć okno Repozytorium Git.

   

2. W oknie Repozytorium Git kliknij prawym przyciskiem myszy gałąź docelową i wybierz polecenie Wyewidencjonuj.

   

3. Kliknij prawym przyciskiem myszy gałąź źródłową i wybierz polecenie Zmień bazę <docelową-gałąź na <gałąź>> źródłową.

   

4. Program Visual Studio wyświetli komunikat potwierdzający po pomyślnym ponownym zdaniu bazy danych.

   

   Jeśli baza bazy danych zostanie zatrzymana z powodu konfliktów scalania, program Visual Studio powiadomi Cię. Możesz rozwiązać konflikty lub anulować rebase i powrócić do stanu bazy wstępnej.

   

Visual Studio 2019 — Team Explorer

Program Visual Studio 2019 w wersji 16.8 lub nowszej zapewnia środowisko kontroli wersji usługi Git przy zachowaniu interfejsu użytkownika programu Git programu Team Explorer . Aby użyć programu Team Explorer, usuń zaznaczenie pozycji Opcje narzędzi>>w wersji zapoznawczej Funkcje>nowego środowiska użytkownika usługi Git na pasku menu. Funkcje usługi Git można używać zamiennie z dowolnego interfejsu.

1. W programie Team Explorer wybierz pozycję Strona główna i wybierz pozycję Gałęzie.

   

2. W widoku Gałęzie kliknij prawym przyciskiem myszy gałąź docelową i wybierz polecenie Wyewidencjonuj.

   

3. Kliknij prawym przyciskiem myszy gałąź źródłową i wybierz polecenie Zmień bazę na.

   

4. Zweryfikuj opcje bazy danych, a następnie kliknij pozycję Zmień bazę danych.

   

5. Program Visual Studio wyświetli komunikat potwierdzający po pomyślnym ponownym zdaniu bazy danych.

   

   Jeśli podczas ponownej bazy wystąpią konflikty, program Visual Studio powiadomi Cię. Możesz rozwiązać konflikty lub anulować rebase i powrócić do stanu bazy wstępnej.

   

Wiersz polecenia usługi Git

Aby zintegrować zatwierdzenia gałęzi źródłowej z gałęzią docelową, uruchom git rebase polecenie:

git rebase <source branch name> <target branch name>

Jeśli bieżąca gałąź lokalna jest gałęzią docelową, możesz uprościć polecenie rebase w celu:

git rebase <source branch name>

Usługa Git powiadomi Cię o konfliktach podczas ponownej bazy danych. Możesz rozwiązać konflikty, a następnie uruchomić polecenie , lub uruchomić git rebase --continuegit rebase --abort polecenie , aby cofnąć bazę danych i wrócić do stanu bazy wstępnej.

Wymusić wypchnięcie gałęzi lokalnej po rebase

Jeśli bazujesz ponownie gałąź lokalną, która została wcześniej wypchnięta, kolejne domyślne wypychanie git zakończy się niepowodzeniem. Zamiast tego możesz wymusić wypchnięcie gałęzi lokalnej, aby zastąpić jego zdalny odpowiednik, aby ich historie zatwierdzeń odpowiadały.

Ostrzeżenie

Nigdy nie wymuszaj wypychania gałęzi, nad którą pracują inni. Aby uzyskać więcej informacji, zobacz Rebase and force push guidelines (Ponowne bazy danych i wymuszanie wypychania).

Aby wymusić wypchnięcie w programie Visual Studio, musisz najpierw włączyć opcję wymuszania wypychania:

1. Przejdź do pozycji Narzędzia>Opcje>Kontroli>źródła Globalne Ustawienia Git.

2. Wybierz opcję Włącz wypychanie --force-with-lease.

Flaga wypychania --force-with-lease Usługi Git jest bezpieczniejsza niż --force flaga, ponieważ nie zastąpi gałęzi zdalnej, która zawiera zatwierdzenia, które nie są zintegrowane w gałęzi lokalnej, którą wymusisz wypychanie.

Visual Studio 2022

1. W oknie Git Changes (Zmiany usługi Git) wybierz przycisk push , aby wypchnąć zatwierdzenie.

   

   Możesz też wybrać pozycję Wypchnij z menu Git .

   

2. Jeśli domyślna operacja wypychania Git zakończy się niepowodzeniem, program Visual Studio uruchomi okno dialogowe Git-Push nie powiodło się . Wybierz pozycję Wymuś wypchnięcie.

   

3. Program Visual Studio wyświetli komunikat potwierdzający po pomyślnym wypchnięciu.

   

Visual Studio 2019 — menu Git

1. W oknie Git Changes (Zmiany usługi Git) wybierz przycisk push , aby wypchnąć zatwierdzenie.

   

   Możesz też wybrać pozycję Wypchnij z menu Git .

   

2. Jeśli domyślna operacja wypychania Git zakończy się niepowodzeniem, program Visual Studio uruchomi okno dialogowe Git-Push nie powiodło się . Wybierz pozycję Wymuś wypchnięcie.

   

3. Program Visual Studio wyświetli komunikat potwierdzający po pomyślnym wypchnięciu.

   

Visual Studio 2019 — Team Explorer

Program Visual Studio 2019 w wersji 16.8 lub nowszej zapewnia środowisko kontroli wersji usługi Git przy zachowaniu interfejsu użytkownika programu Git programu Team Explorer . Aby użyć programu Team Explorer, usuń zaznaczenie pozycji Opcje narzędzi>>w wersji zapoznawczej Funkcje>nowego środowiska użytkownika usługi Git na pasku menu. Funkcje usługi Git można używać zamiennie z dowolnego interfejsu.

1. W programie Team Explorer wybierz pozycję Strona główna, a następnie wybierz pozycję Synchronizuj, aby otworzyć widok Synchronizacja.

   

2. W widoku Synchronizacja wybierz pozycję Wypchnij, aby przekazać zmiany do repozytorium zdalnego.

   

3. Jeśli domyślna operacja wypychania Git zakończy się niepowodzeniem, program Visual Studio uruchomi okno dialogowe Git-Push nie powiodło się . Wybierz pozycję Wymuś wypchnięcie.

   

4. Program Visual Studio wyświetli komunikat potwierdzający po pomyślnym wypchnięciu.

   

Wiersz polecenia usługi Git

Napiwek

Flaga wypychania --force-with-lease Usługi Git jest bezpieczniejsza niż --force flaga, ponieważ nie zastąpi gałęzi zdalnej, która zawiera zatwierdzenia, które nie są zintegrowane w gałęzi lokalnej, którą wymusisz wypychanie.

Aby wymusić wypchnięcie nowych zatwierdzeń z gałęzi lokalnej do gałęzi zdalnej o tej samej nazwie:

git push --force-with-lease <remote> <local branch name>

Jeśli gałąź, którą chcesz wypchnąć, to wyewidencjonowana gałąź, możesz uprościć wymuszanie wypychania polecenia w celu:

git push --force-with-lease <remote>

Podczas klonowania repozytorium zdalnego usługa Git przypisuje alias origin jako skrócony adres URL sklonowanego repozytorium zdalnego. Uruchom polecenie , git remote -v aby sprawdzić wartość aliasu origin . Aby ręcznie dodać origin alias, uruchom polecenie git remote add origin <remote repo url>. Za pomocą aliasu origin można jeszcze bardziej uprościć wymuszanie polecenia wypychania:

git push --force-with-lease origin

Jeśli bieżąca gałąź lokalna śledzi gałąź zdalną w systemie origin, możesz w pełni skrócić polecenie wymuszania wypychania:

git push --force-with-lease

Jednak w pełni skrócone polecenie wypychania zakończy się niepowodzeniem, jeśli gałąź lokalna nie śledzi gałęzi zdalnej. Uruchom polecenie , git remote show origin aby sprawdzić śledzony stan gałęzi.

Interakcyjna ponowna baza danych do zatwierdzeń lokalnych zmiecenia lokalnego

Zazwyczaj podczas pracy nad nową funkcją w lokalnej gałęzi funkcji utworzysz wiele zatwierdzeń. Gdy wszystko będzie gotowe do opublikowania nowej funkcji, możesz skonsolidować te zatwierdzenia w jednym zatwierdzeniu, aby uprościć historię zatwierdzeń. Możesz użyć interakcyjnej bazy danych, aby zmiażdżyć wiele zatwierdzeń w jednym zatwierdzeniu.

Visual Studio 2022

Program Visual Studio 2022 nie obsługuje interaktywnego ponownego łączenia. Zamiast tego użyj wiersza polecenia usługi Git.

Visual Studio 2019 — menu Git

Program Visual Studio 2019 nie obsługuje interaktywnego ponownego łączenia. Zamiast tego użyj wiersza polecenia usługi Git.

Visual Studio 2019 — Team Explorer

Program Visual Studio 2019 nie obsługuje interaktywnego ponownego łączenia. Zamiast tego użyj wiersza polecenia usługi Git.

Wiersz polecenia usługi Git

1. Zapoznaj się z gałęzią lokalną, na której chcesz wykonać interaktywną bazę danych.

2. Zatwierdź, stash lub odrzuć wszelkie niezatwierdzone zmiany.

3. Szacuj, jak daleko w historii zatwierdzń chcesz przejść. Nie musisz być dokładnie tak, jak będzie można wybrać określone zatwierdzenia do squasha po uruchomieniu interaktywnego polecenia rebase. Jeśli na przykład chcesz zmieścić zatwierdzenia w ciągu ostatnich pięciu zatwierdzeń, uruchom polecenie:

   git rebase -i HEAD~5
   

   Usługa Git otworzy edytor zawierający listę ostatnich pięciu zatwierdzeń, począwszy od najnowszych. Na przykład:

   pick 7068b09 Update README network switch section
   pick 9d247f7 Update README network controller section
   pick 5d7ab9f Fix fiber optic transmitter test
   pick 7b43f3f Add network switch test
   pick 00859d9 Add network controller test
   

4. Pozostaw pierwszy wiersz w następujący sposób. W kolejnych wierszach, aby scalić zatwierdzenie z tym, które powyżej, zmień na pick squash. Aby na przykład połączyć dwa pierwsze zatwierdzenia, a także dwa dolne zatwierdzenia, zmodyfikuj listę zatwierdzeń na:

   pick 7068b09 Update README network switch section
   squash 9d247f7 Update README network controller section
   pick 5d7ab9f Fix fiber optic transmitter test
   pick 7b43f3f Add network switch test
   squash 00859d9 Add network controller test
   

5. Zapisz plik i zamknij edytor. Usługa Git otworzy nowy edytor dla każdego zestawu scalonych zatwierdzeń z monitem o wprowadzenie komunikatu zatwierdzenia. Dla każdego zestawu zatwierdzń skondensuj komunikaty zatwierdzenia w dół do jednego komunikatu, a następnie zapisz i zamknij edytor. W poprzednim przykładzie zatwierdzenia zgniecione są skondensowane z nowymi komunikatami zatwierdzenia:

   8fcb88f Update README network sections
   ac6d3c0 Fix fiber optic transmitter test
   f0aadc3 Add two network tests
   

   Mimo że zatwierdzenie Fix fiber optic transmitter test nie zostało zgniecione, ma on nowy identyfikator zatwierdzenia, ponieważ teraz łączy się z innym zatwierdzeniem poprzednika.

Aby uzyskać więcej informacji na temat interakcyjnego ponownego łączenia, zobacz Tryb interaktywny bazy danych Git.

Uwaga

Użytkownicy usługi Azure DevOps mogą scalać dane , aby skondensować historię zatwierdzeń gałęzi tematu podczas żądania ściągnięcia.

Następne kroki

Kopiowanie zmian za pomocą funkcji cherry-pick

Powiązane artykuły

• Dopiero zaczynasz korzystać z repozytoriów Git? Dowiedz się więcej
• Udostępnianie kodu za pomocą wypychania
• Aktualizowanie kodu przy użyciu pobierania, scalania i ściągania