Rozgałęzianie i scalanie zmian

  • 6 min

Gdy pracujesz nad kodem Bicep, często trzeba zrobić więcej niż jedną rzecz naraz. Na przykład poniżej przedstawiono dwa scenariusze pracy z witryną internetową firmy z toy:

  • Zespół programistyczny Twojej witryny internetowej chce pomóc w aktualizowaniu plików Bicep ze znaczącymi zmianami. Jednak zespół nie chce, aby te zmiany były jeszcze na żywo. Musisz mieć możliwość dostosowania drobnych poprawek do bieżącej wersji na żywo witryny internetowej równolegle z pracą nad nową wersją.
  • Pracujesz nad eksperymentalnymi zmianami, które według Ciebie pomogą poprawić wydajność witryny internetowej. Jednak te zmiany są wstępne. Nie chcesz ich stosować do wersji na żywo witryny internetowej, dopóki nie wszystko będzie gotowe.

W tej lekcji poznasz gałęzie usługi Git.

Uwaga

Polecenia w tej lekcji są wyświetlane w celu zilustrowania pojęć. Nie uruchamiaj jeszcze poleceń. Wkrótce dowiesz się, czego nauczysz się tutaj.

Co to są gałęzie?

Gałąź umożliwia posiadanie wielu aktywnych kopii plików. Możesz tworzyć i przełączać się między gałęziami zawsze, gdy chcesz. Po zakończeniu pracy z gałęzią można scalić ją z inną gałęzią. Można go też usunąć, co spowoduje usunięcie wszystkich zmian.

Często używa się gałęzi dla całej pracy. Często należy wyznaczyć jedną gałąź jako gałąź podstawową, która reprezentuje znaną dobrą lub żywą wersję plików. Zgodnie z konwencją ta gałąź jest zwykle nazywana główną. Możesz utworzyć dowolną liczbę innych gałęzi. Gdy zmiany w gałęzi są gotowe, scalisz gałąź z gałęzią główną .

Tworzenie i wyewidencjonowywanie gałęzi

Tworzenie gałęzi jest szybkie i łatwe w usłudze Git. Istnieje kilka sposobów, aby to zrobić, ale najprostszym sposobem jest zwykle użycie git checkout polecenia . Oto przykład tworzenia nowej gałęzi o nazwie my-experimental-changes:

git checkout -b my-experimental-changes

To polecenie wykonuje dwie rzeczy: tworzy gałąź my-experimental-changes i sprawdza nowo utworzoną gałąź. Wyewidencjonowanie oznacza, że kopia plików widocznych w folderze będzie odzwierciedlać to, co znajduje się w gałęzi. Jeśli masz dwie gałęzie z różnymi zestawami zmian, wyewidencjonuj jedną gałąź, a druga umożliwia przerzucanie między dwoma zestawami zmian.

Możesz też przełączyć się do istniejącej gałęzi za pomocą git checkout polecenia . W tym przykładzie wyewidencjonujesz gałąź główną :

git checkout main

Uwaga

Zwykle należy zatwierdzić zmiany, zanim będzie można wyewidencjonować inną gałąź. Usługa Git wyświetli ostrzeżenie, jeśli nie możesz wyewidencjonować.

Praca nad gałęzią

Po przełączeniu do gałęzi pliki są zatwierdzane tak jak zwykle. W rzeczywistości wszystko, co zrobiłeś, było teraz w gałęzi. Pracujesz nad gałęzią główną , która jest gałęzią domyślną podczas tworzenia nowego repozytorium.

Po zatwierdzeniu niektórych zmian podczas wyewidencjonowane gałęzi zatwierdzenie jest skojarzone z gałęzią. Po przełączeniu do innej gałęzi prawdopodobnie nie zobaczysz zatwierdzenia w git log historii, dopóki nie scalisz gałęzi.

Scal gałęzie

Gałęzie to doskonały sposób oddzielenia pracy w toku od bieżącej wersji na żywo kodu Bicep. Jednak po zakończeniu wprowadzania zmian w plikach w gałęzi często chcesz scalić zmiany z gałęzią główną .

Podczas pracy nad jedną gałęzią możesz scalić zmiany innej gałęzi w bieżącej git merge gałęzi przy użyciu polecenia .

Uwaga

Przed scaleniem należy sprawdzić gałąź docelową scalania (często nazywaną gałęzią docelową ). Pamiętaj, że scalasz z innej gałęzi do bieżącej gałęzi roboczej.

Oto przykład pokazujący, jak można wyewidencjonować gałąź główną , a następnie scalić zmiany z gałęzi my-experimental-changes w gałęzi głównej . Na koniec usuniesz gałąź my-experimental-changes , ponieważ nie jest już potrzebna.

git checkout main
git merge my-experimental-changes
git branch -d my-experimental-changes

Porada

Podczas pracy z innymi osobami często używa się żądań ściągnięcia do scalania zmian zamiast bezpośrednio scalać gałęzie. Wkrótce dowiesz się więcej na temat żądań współpracy i ściągnięcia.

Konflikty scalania

Gdy usługa Git scala zmiany z jednej gałęzi na inną, analizuje zmodyfikowane pliki i próbuje scalić zmiany razem. Czasami mogą zostać wprowadzone zmiany w tych samych wierszach kodu w dwóch różnych gałęziach. W takich sytuacjach usługa Git nie może wybrać odpowiedniej wersji kodu, dlatego zamiast tego utworzy konflikt scalania.

Nie omawiamy konfliktów scalania w głębi tego modułu, ale ważne jest, aby wiedzieć, że mogą wystąpić konflikty scalania. Częściej współpracujesz z innymi osobami. W podsumowaniu tego modułu udostępniamy link do dodatkowych informacji na temat sposobu, w jaki usługa Git i Visual Studio Code ułatwiają rozwiązywanie konfliktów scalania.

Przepływy pracy usługi Git

W tym module poznasz tylko podstawy gałęzi. Jednak gałęzie są potężne i zapewniają elastyczność w sposobie pracy. Można na przykład utworzyć gałęzie poza innymi gałęziami i scalić gałąź z dowolną inną gałęzią. Możesz użyć gałęzi, aby utworzyć różnego rodzaju przepływy pracy , które obsługują sposób, w jaki ty i twój zespół lubią pracować.

W tym module używamy prostego przepływu pracy nazywanego programowaniem opartym na magistrali. W tym przepływie pracy istnieje pojedyncza gałąź magistrali . Na przykład w przykładach tego artykułu używamy głównej nazwy. Ta gałąź reprezentuje znaną dobrą wersję kodu. Gałęzie są tworzone poza tym magistralą podczas wprowadzania zmian lub wykonywania dowolnej pracy.

Programowanie oparte na magistrali zniechęca do wprowadzania zmian bezpośrednio w gałęzi magistrali. Próbujesz zachować inne gałęzie tylko przez krótki czas, co pomaga zminimalizować konflikty scalania. Następnie scalisz i usuniesz te gałęzie podczas wykonywania zadań.

Istnieją inne przepływy pracy, które są wspólne w środowiskach zespołowych, w których warto kontrolować częstotliwość wydawania zmian. W podsumowaniu tego modułu udostępniamy linki do dodatkowych informacji o przepływach pracy usługi Git.