Rozgałęzianie i scalanie zmian

Ukończone

Podczas pracy nad kodem Bicep często trzeba wykonać więcej niż jedną czynność 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 przy użyciu znaczących zmian. Jednak zespół nie chce, aby te zmiany były jeszcze aktywne. Musisz mieć możliwość wprowadzania 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 stosować ich do wersji na żywo witryny internetowej, dopóki nie będziesz gotowy.

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

Uwaga

Polecenia w tej lekcji są pokazane w celu zilustrowania pojęć. Nie uruchamiaj jeszcze poleceń. Będziesz ćwiczyć to, czego nauczysz się tutaj wkrótce.

Co to są gałęzie?

Gałąź umożliwia posiadanie wielu aktywnych kopii plików. W dowolnym momencie możesz tworzyć gałęzie i przełączać się między nimi. Po zakończeniu pracy z gałęzią można scalić ją z inną gałęzią. Możesz też go 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 dynamiczną 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, scalasz 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 faktycznie wykonuje dwie czynności: tworzy gałąź my-experimental-changes i sprawdza nowo utworzoną gałąź. Wyewidencjonowanie oznacza, że kopia plików widocznych w folderze będzie odzwierciedlać zawartość gałęzi. Jeśli masz dwa gałęzie z zupełnie różnymi zestawami zmian, wyewidencjonuj jedną gałąź, a następnie drugą 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łąź. Jeśli nie możesz wyewidencjonować, usługa Git wyświetli ostrzeżenie.

Praca nad gałęzią

Po przełączeniu do gałęzi zatwierdzanie plików jest podobne do normalnych. W rzeczywistości wszystko, co zostało zrobione do tej pory, było 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 będzie widoczne zatwierdzenie w git log historii do momentu scalenia gałęzi.

Scal gałęzie

Gałęzie to doskonały sposób oddzielenia pracy w toku od bieżącej wersji kodu Bicep na żywo. 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żna scalić zmiany innej gałęzi z bieżącą gałęzią git merge 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 z bieżącą gałęzią roboczą.

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

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średniego scalania gałęzi. Wkrótce dowiesz się więcej o współpracy i żądaniach ściągnięcia.

Konflikty scalania

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

Nie omawiamy szczegółowo konfliktów scalania w tym module, ale ważne jest, aby wiedzieć, że może się to zdarzyć. I jest jeszcze bardziej powszechne, gdy współpracujesz z innymi osobami. W podsumowaniu tego modułu udostępniamy link do dodatkowych informacji na temat sposobu rozwiązywania konfliktów scalania w usłudze Git i Visual Studio Code.

Przepływy pracy usługi Git

W tym module poznasz tylko podstawy gałęzi. Jednak gałęzie są potężne i zapewniają dużą elastyczność w sposobie pracy. Można na przykład tworzyć gałęzie poza innymi gałęziami i scalać gałąź z dowolną inną gałęzią. Za pomocą gałęzi można tworzyć różne rodzaje różnych przepływów 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 jedna gałąź magistrali . (Używaliśmy narzędzia main). Ta gałąź reprezentuje znaną dobrą wersję kodu. Gałęzie są tworzone poza tym magistralą podczas wprowadzania zmian lub wykonywania jakiejkolwiek pracy.

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

Istnieją też inne przepływy pracy. Są one powszechne w środowiskach zespołowych, w których można kontrolować, jak często są wydawane zmiany. W podsumowaniu tego modułu udostępniamy linki do dodatkowych informacji na temat przepływów pracy usługi Git.