Jeśli piszesz oprogramowanie w 2018 roku, to mogę śmiało powiedzieć, że znasz Git. Narzędzie stworzone przez Linusa Torvaldsa stało się synonimem kontroli wersji. Bez wątpienia jedną z najlepszych funkcji Gita jest to, jak usuwa ból związany z rozgałęzianiem i scalaniem. Oddział w Git można utworzyć na kilka sposobów. W tym poście omówimy niektóre z nich. Następnie zakończymy krótką refleksją na temat modelu rozgałęziania Gita i ogólnie rozgałęzień.

Tworzenie gałęzi na podstawie wzorca

Tworzysz gałęzie w Git, co nie jest zaskakujące, za pomocą polecenia branch. Podobnie jak wiele innych poleceń Git, „branch” jest bardzo potężny i elastyczny. Oprócz tworzenia gałęzi, może być również używany do ich wyświetlania i usuwania, a także możesz dalej dostosowywać polecenie, wykorzystując szeroką listę parametrów. Zaczniemy od pierwszego sposobu tworzenia gałęzi. Powiedzmy, że chcesz utworzyć nowy folder o nazwie „moja-aplikacja”, wejdź do niego i uruchom nowe repozytorium Git. Dokładnie tak byś to zrobił:

Masz teraz nowe, puste repozytorium Git. Ale puste repozytoria są nudne. A co z utworzeniem nowego pliku przeceny z napisem „Hello World!”?

echo Hello World! > file.md

Jeśli uruchomisz „git status”, powinieneś zobaczyć komunikat informujący, że Twój plik nie jest śledzony:

Nieśledzone pliki też są niefajne, więc prześledźmy to:

git add file.md

Na koniec stwórzmy nasze pierwsze zatwierdzenie:

git commit -m "First commit"

Mamy teraz repozytorium z jedną gałęzią, która ma dokładnie jedno zatwierdzenie. To może nie brzmieć jak najbardziej ekscytująca rzecz na świecie (bo tak naprawdę nie jest), ale z pewnością jest mniej nudna niż posiadanie repozytorium bez żadnych zatwierdzeń, prawda? Teraz powiedzmy, że z jakiegokolwiek powodu musisz zmienić plik „s treści. Ale ty nie mam ochotę to zrobić. A jeśli coś pójdzie nie tak i w jakiś sposób zepsujesz piękną, nieskazitelną zawartość swojego pliku? (Tak, wiem, że to tylko jakiś głupi plik z napisem „Hello World!”, Ale użyj cudownych mocy swojej wyobraźni i potraktuj plik jako proxy dla znacznie bardziej złożonego projektu.) Rozwiązanie tego dylematu to oczywiście utworzenie nowej gałęzi:

git branch exp

Mamy teraz nową gałąź o nazwie „exp” do eksperymentów . Niektórzy ludzie, którzy są przyzwyczajeni do używania różnych systemów wersjonowania, zwłaszcza scentralizowanych, mogą powiedzieć, że gałęzie mają tę samą „zawartość”. Nie jest to jednak do końca poprawne, jeśli chodzi o Git. Pomyśl o gałęziach jak o odniesieniach wskazujących na dane zatwierdzenie.

Tworzenie gałęzi na podstawie zatwierdzenia

Załóżmy, że z jakiegokolwiek powodu zrezygnujemy z naszego eksperymentu, bez dodawania ani jednej zobowiązać się do nowej gałęzi. Wróćmy do mastera i usuń gałąź exp:

git checkout mastergit branch -d exp

Teraz, gdy wróciliśmy do jednej gałęzi, dodajmy do tego kilka zatwierdzeń, aby zasymulować wykonywaną pracę:

Wyobraź sobie, że po wykonaniu całej tej „pracy” uczysz się, że z jakiegoś powodu musisz cofnąć się w czasie były tylko dwie linie w pliku i od tej pory utwórz nowe zmiany. Ale jednocześnie musisz zachować postęp, który już zrobiłeś. Innymi słowy, chcesz utworzyć gałąź z poprzedniego zatwierdzenia. Jak byś to zrobił ? W Git każde zatwierdzenie ma unikalny identyfikator. Możesz więc łatwo to zobaczyć za pomocą polecenia „git log”. Aby utworzyć nową gałąź na podstawie określonego zatwierdzenia, po prostu przekaż jego hash jako parametr do polecenia branch:

git branch new-branch 7e4decb

Poza tym przez większość czasu nie potrzebujesz nawet całego skrótu. Wystarczy pierwszych pięć lub sześć znaków.

Tworzenie gałęzi na podstawie tagu

Jeśli masz nieco większe doświadczenie w Git, powinieneś znać pojęcie tagów. Używasz tagów, aby wskazać, że dane zatwierdzenie jest w jakiś sposób ważne lub szczególne. Na przykład tagi są zwykle używane do wskazania rzeczywistych wersji produktu. Jeśli pracujesz w aplikacji przez jakiś czas i Uważasz, że nadszedł czas, aby wydać wersję 1.0. Zwykle robisz to, gdy jest to konieczne, podbijając numery wersji, zatwierdzając te zmiany, a następnie dodając znacznik w tym konkretnym momencie. Aby utworzyć tag, zwykle uruchamiasz coś takiego:

git tag -a v1.0 -m "First major version"

Parametr „-a” wskazuje, że to się dzieje jako tag z adnotacją. W przeciwieństwie do lekkiego tagu, jest to pełnowymiarowy obiekt Git, zawierający fragmenty informacji, takie jak imię i nazwisko oraz adres e-mail autora, sygnatura czasowa i wiadomość. Teraz masz tag, wskazujący, że ten konkretny punkt w historii jest wyjątkowy i ma nazwę. Miły. Możesz kontynuować pracę, jak zwykle, tworząc i zatwierdzając zmiany, które będą częścią wersji 1.1. Dopóki nie pojawi się raport o błędzie. Niektórzy klienci zaktualizowani do wersji 1.Wersja 0 produktu mówi, że funkcja importu nie działa zgodnie z przeznaczeniem. Cóż, teoretycznie można naprawić błąd w gałęzi głównej i wdrożyć go. Ale wtedy klienci otrzymają funkcje, które są potencjalnie nieprzetestowane i niekompletne. -Nie. Więc co robisz? Odpowiedź: tworzysz nową gałąź ze znacznika, który utworzyłeś, aby wskazać wersję główną. Naprawiasz tam problem, budujesz i wdrażasz. I prawdopodobnie powinieneś później scalić to z powrotem do mastera, więc następne wydania zawierają poprawkę . Jak byś się do tego zabrał? Łatwe:

git branch <NAME-OF-THE-BRANCH> <TAG>

Dokładniej, korzystając z naszego poprzedniego przykładu:

git branch fix-bug-123 v1.0

Następnie możesz jak zwykle sprawdzić swój nowy oddział. Albo jeszcze lepiej, możesz to wszystko zrobić w jednym kroku:

git checkout -b fix-bug-1234 v1.0

Tworzenie oddziału w stanie odłączonej głowy

Czy kiedykolwiek chciałeś cofnąć się w czasie? Dzięki Git jest to możliwe … przynajmniej w odniesieniu do plików w naszym repozytorium. Możesz w dowolnym momencie sprawdzić zatwierdzenie, jeśli znasz jego hash:

git checkout <SHA1>

Po uruchomieniu tego, Git pokaże Ci ciekawą wiadomość:

You are in "detached HEAD" state. You can look around, make experimentalchanges and commit them, and you can discard any commits you make in thisstate without impacting any branches by performing another checkout.

Kiedy wyewidencjonujesz zatwierdzenie, wchodzisz w specjalny stan c alled, jak widać, „odłączona GŁOWA”. Chociaż możesz zatwierdzać zmiany w tym stanie, te zatwierdzenia nie należą do żadnej gałęzi i staną się niedostępne, gdy tylko sprawdzisz inną gałąź. Ale co, jeśli chcesz zachować te zatwierdzenia? Odpowiedzią, co nie jest zaskakujące, jest użycie polecenie „checkout” ponownie, aby utworzyć nową gałąź:

git checkout <sha1> #now you"re in detached head state# do some work and stage itgit commit -m "add some work while in detached head state"git branch new-branch-to-keep-commitsgit checkout new-branch-to-keep-commits

I oczywiście już wiesz, że możesz napisać ostatnie dwie linie jako jedno polecenie:

git checkout -b new-branch-to-keep-commits

Całkiem proste, prawda?

Tylko dlatego, że możesz … To nie znaczy, że powinieneś

Model rozgałęzień Gita jest jednym z jego punktów sprzedaży. Zmienia to, co w innych systemach kontroli źródła jest bolesnym, a nawet powolnym procesem, w pestkę. Można powiedzieć że Git z powodzeniem zdemokratyzował rozgałęzianie dla mas. Ale istnieje poważne niebezpieczeństwo. Ze względu na taniość rozgałęziania w Git, niektórzy programiści mogą wpaść w pułapkę pracy z bardzo długimi gałęziami lub wykorzystywania przepływów pracy lub modeli rozgałęziających, które opóźniają gracja. My, jako branża, tam byliśmy. Zrobiliśmy to. To nie działa. Zamiast tego zastosuj przepływy pracy, które wykorzystują bardzo krótkotrwałe gałęzie. Będziesz mieć bezpieczną piaskownicę, w której możesz kodować bez obawy o zepsucie rzeczy lub marnowanie czasu współpracowników. Ale czy to powoduje, że pytasz: „Jak wdrożyć kod z częściowo ukończonymi funkcjami?” W takim przypadku na ratunek przychodzą flagi funkcji. Gałęzie Git są potężnym narzędziem. Używaj ich mądrze i nie nadużywaj ich. A kiedy „nie wystarczą”, zastosuj ciągłe dostarczanie / ciągłą integrację wraz z flagami funkcji – w tym specjalistycznymi narzędziami do Twojej dyspozycji – aby Twoje aplikacje mogły przejść na wyższy poziom.