Rozgałęzianie i scalanie zmian
Podczas pracy nad kodem Bicep często trzeba wykonać więcej niż jedną czynność naraz. Oto na przykład dwa scenariusze pracy z witryną internetową twojej 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 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ń. Będziesz ćwiczyć to, czego nauczysz się tutaj wkrótce.
Co to są gałęzie?
Gałąź umożliwia posiadanie wielu aktywnych kopii plików. Możesz tworzyć gałęzie i przełączać się między nimi zawsze, gdy chcesz. Po zakończeniu pracy z gałęzią można ją scalić z inną gałęzią. Możesz go również 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 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 z gałęzią
Po przełączeniu do gałęzi pliki są zatwierdzane tak jak zwykle. W rzeczywistości wszystko, co zrobiłeś, było na 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 się 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 powrotem do gałęzi głównej.
Podczas pracy nad jedną gałęzią można scalić zmiany innej gałęzi w bieżącej gałęzi przy użyciu git merge polecenia .
Uwaga
Przed scaleniem należy wyewidencjonować 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 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
Napiwek
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 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 mogły 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ć poprawnej 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 mogą wystąpić konflikty scalania. I jest to bardziej powszechne, gdy współpracujesz z innymi osobami. W podsumowaniu tego modułu udostępnimy link do dodatkowych informacji na temat sposobu rozwiązywania konfliktów scalania w usługach Git i Visual Studio Code.
Przepływy pracy usługi Git
W tym module poznasz tylko podstawy gałęzi. Jednak gałęzie są zaawansowane 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óż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 pojedyncza gałąź magistrali . Na przykład w przykładach tego artykułu używamy głównych elementów. 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ć, jak często zwalniasz zmiany. W podsumowaniu tego modułu udostępniamy linki do dodatkowych informacji na temat przepływów pracy usługi Git.