Zaawansowane przepływy pracy i użytkowanie Git

Niedawno przyjrzeliśmy się podstawom rozpoczęcia korzystania z usługi Git do kontroli źródeł w projektach. Chociaż jest to świetny punkt wyjścia, istnieje wiele innych poleceń i przepływów pracy Git, które pomogą Ci w codziennej pracy nad kodowaniem za pomocą Git.

Przepływy pracy w Git

Kiedy zacząłem używać Gita, pomyślałem, że wiem, jak go właściwie używać. Moim idealnym podejściem było wprowadzanie wszystkich zmian w jednym miejscu bez rozgałęzień, a następnie umieszczanie ich w repozytorium i kontynuowanie pracy.

Chociaż było to lepsze niż nieużywanie kontroli wersji, zajęło mi trochę czasu, zanim zdałem sobie sprawę, że nie używam większości mocy, którą zapewniał Git. Aby Git działał dla mnie, musiałem mieć strategię rozgałęziania i scalania zmian.

Potem wyszedł git-flow i przyjąłem go jako swoją strategię. Wciąż pamiętam uczucie, jakbym zaglądał za jakąś kurtynę tam, gdzie byli niesamowici programiści. Miałem teraz wgląd w to, jak oni pracowali i mogli zacząć stać się jednym z nich.

Ale git-flow nie pasuje do każdego scenariusza, więc gdy przyjrzymy się temu, przyjrzymy się również kilku innym metodom organizowania projektów Git, w tym tym, jak zarządzam moimi projektami jako samotny programista.

przepływ git

Patrząc teraz na git-flow, zdaję sobie sprawę, że krajobraz oprogramowania bardzo się zmienił w ciągu 10 lat i git-flow może nie być najlepszą opcją dla twojego zespołu. Kiedy napisano git-flow, rzadko zdarzało się wdrażać aplikację wiele razy w ciągu dnia. Zamiast tego prawdopodobnie zrobiłeś główny numer wersji i wypuszczałeś co kilka miesięcy lub tygodni, jeśli byłeś w szczególnie zwinnym zespole.

Przyjrzyjmy się, czym jest git-flow.

Jeśli chcesz zobaczyć pełne, szczegółowe wyjaśnienie z wykresami i poleceniami Git dla Git Flow, powinieneś przeczytać ten post.

W git-flow dwie gałęzie mają nieskończoną żywotność. Po pierwsze, główny, który powinien odzwierciedlać kod gotowy do wdrożenia w Twoim środowisku live/produkcyjnym.

Po drugie, mamy swoją gałąź deweloperską. Ta gałąź powinna zawierać najnowsze zmiany, które są gotowe do następnej wersji naszego oprogramowania. Gdy zmiany w developerze są gotowe do wdrożenia w naszej działającej aplikacji, łączymy je z główną gałęzią i oznaczamy numerem wersji, który odpowiada numerowi wydania.

Poza dwiema głównymi gałęziami istnieją trzy rodzaje gałęzi wspierających.

1. Funkcja

Gałąź funkcji może być wykonana tylko z gałęzi deweloperskiej. Musi zostać z powrotem scalony z gałęzią deweloperską. Nazewnictwo może zawierać opis funkcji, nad którą pracujesz.

Gdy praca jest gotowa do następnego wydania, zostaje z powrotem scalona z gałęzią deweloperską, gdzie czeka na czas wydania.

2. Zwolnij

Gałęzie wydania są tworzone z gałęzi deweloperskiej i muszą zostać ponownie połączone z gałęzią deweloperską i główną. Gałąź wydania nazywasz konwencją release-x. W praktyce zwykle oznacza to, że nazwałbyś oddział z numerem wydania, którego planujesz użyć w następujący sposób: release-2.2

Używasz gałęzi wydania jako sposobu na ostateczne przygotowanie do wydania oprogramowania. Może to obejmować zwiększenie numeru wersji plików, upewnienie się, że tłumaczenia są wykonane lub ostateczne sprawdzenie kodu.

3. Poprawka

Gałąź hotfix jest tworzona z gałęzi głównej i służy do przechowywania zmian, które należy natychmiast rozwiązać w działającej aplikacji. Może to być błąd, który należy naprawić lub problem z bezpieczeństwem, którym należy się zająć.

Gdy problem zostanie rozwiązany i wdrożony w głównym oddziale, oznaczysz swój kod odpowiednim numerem wersji.

Największym powodem, dla którego zespoły nie używają teraz git-flow, jest to, że zmienił się sposób, w jaki wydajemy oprogramowanie. Zamiast większych wydań rzadziej, możesz wydać zmianę w aplikacji kilka razy dziennie. Wiem, że pcham pracę na strony mojego klienta wiele razy w tygodniu, gdy tylko będzie gotowa. Nie robimy numerów wersji witryny, po prostu ją ulepszamy.

Standardowy przepływ git nie jest przeznaczony do tego.

Przepływ na Github

Drugą opcją, z której korzysta wiele osób, jest Github Flow.

Główną zasadą Github Flow jest to, że każdy kod znajdujący się w głównej gałęzi może zostać wdrożony w dowolnym momencie, ponieważ jest gotowy do produkcji.

Wszystkie gałęzie są tworzone z głównej gałęzi z opisową nazwą dla tego, co robisz.

Po przygotowaniu zmian utwórz żądanie ściągnięcia.

Żądania ściągnięcia informują inne osoby pracujące nad tym samym kodem, że praca, którą wykonujesz, jest gotowa do przeglądu, zanim te zmiany zostaną scalone z kodem głównym.

Po przesłaniu żądania ściągnięcia zespół, z którym pracujesz, może przejrzeć zmiany i przekazać opinię. Jeśli żądanie ściągnięcia zostanie uznane za gotowe do scalenia, zostanie scalone z główną gałęzią projektu.

Jedną z wad przepływu Github dla pojedynczego programisty lub bardzo małego zespołu jest to, że administrowanie żądaniem ściągnięcia może spowodować dodatkowe obciążenie związane z zarządzaniem projektem. Dlatego nie wykorzystuję ich w swojej pracy.

Jak korzystam z przepływów pracy Git w projektach klientów

W mojej pracy z klientem zwykle jestem jedynym, który codziennie pisze kod do projektu. Mój klient może aktualizować wtyczki do WordPressa lub zmieniać niektóre CSS, ale nie wykonują one większych prac związanych z kodowaniem. Oznacza to, że gdybym korzystał z przepływu Github, przeglądałbym moje żądania ściągnięcia, które powodują tylko dodatkowe bóle głowy związane z zarządzaniem. Przyjrzyjmy się systemowi, którego używam, który przypomina trochę zarówno git-flow, jak i Github.

Mam dwie główne gałęzie: główną i inscenizacyjną. Główna gałąź śledzi z dowolnym kodem, który jest aktualnie uruchomiony w witrynie produkcyjnej. Gałąź pomostowa śledzi ze wszystkim, co jest testowane w witrynie pomostowej, której używamy do testowania zmian przed przekazaniem ich do działającej witryny.

Każda gałąź jest tworzona z głównej gałęzi. Nowe funkcje otrzymują taką nazwę: funkcja/32-nowa-funkcja. W tym kontekście liczba 32 odpowiada numerowi zgłoszenia w naszym systemie zarządzania projektami, a słowa po nim są krótkim opisem tego, nad czym pracujemy. Poprawki są nazywane podobnie, bug/20-nazwa-błędu.

Każda stworzona gałąź jest najpierw włączana do gałęzi pomostowej, a następnie po zatwierdzeniu przez klienta lub przetestowana przeze mnie zostaje włączona do gałęzi master. Ten przepływ pracy może wyglądać tak.

# włącz funkcję do gałęzi pomostowej

funkcja łączenia git/32-nowa-funkcja

# wdróż i przetestuj funkcję

git kasa główna

funkcja łączenia git/32-nowa-funkcja

# wdróż funkcję w witrynie na żywo

W moich projektach mam skonfigurowane ciągłe wdrażanie, co oznacza, że ​​za każdym razem, gdy wypycham kod do main, jest on automatycznie przesyłany do działającej witryny. Ten sam proces jest skonfigurowany dla gałęzi tymczasowej.

Gdybym pracował z zespołem, który mógłby sprawdzić mój kod w przepływie pracy pull request, użyłbym tego systemu, ponieważ działa dobrze w zespole. Dla programisty pracującego głównie na własną rękę, to po prostu ogólne koszty zarządzania spowalniają przepływ pracy.

Zaawansowane polecenia Git, których używam

Teraz, gdy mamy już pewne pojęcie o tym, jak możemy użyć Git w praktycznym przepływie pracy, przyjrzyjmy się bardziej zaawansowanym poleceniom, które będą potrzebne, aby tak się stało. Każdego z tych poleceń używam przynajmniej kilka razy w tygodniu podczas pracy z kodem klienta.

Nawet jeśli zamierzasz używać aplikacji z graficznym interfejsem użytkownika (wspomniałem kilka dobrych w moim ostatnim poście na Git), nadal ważne jest, aby rozumieć, co dzieje się w tle. Wiele razy musiałem pracować przez terminal, aby naprawić problem, który został stworzony przez aplikację GIT GUI.

Dodawanie zmian według linii

Jedynym poleceniem, które spowodowało użycie Gita za pośrednictwem terminala, było dla mnie git add -p. Dopóki nie nauczyłem się tego polecenia, korzystałem z aplikacji GUI, ponieważ wprowadzałem zmiany w moim kodzie, ale chcę podzielić określone wiersze na różne zatwierdzenia, abym mógł wyjaśnić, dlaczego dokonałem zmiany. Aby to zrobić, użyłem GUI do wybrania linii, ale git add -p prowadzi cię przez interaktywny interfejs, aby dodać zmiany w porcjach.

Używam tego wiele razy każdego dnia.

Śledź zdalny oddział Git

Jeśli ściągasz istniejące repozytorium i masz gałęzie, takie jak main i pomostowe, które musisz śledzić, ale już istnieją, musisz poinformować lokalne wersje gałęzi, aby śledziły te zdalne wersje gałęzi.

Jest na to kilka sposobów.

# Ustaw upstream podczas pchania do zdalnego

git push -u origin inscenizacja

# Ustaw upstream

# zakłada, że ​​jesteś na gałęzi, którą chcesz aktualnie śledzić za pomocą pilota

git branch -u pochodzenie/staging

git branch --set-upstream-to=origin/staging

# Jeśli nie jesteś na gałęzi, którą chcesz śledzić, podaj gałąź na końcu

git branch --set-upstream-to=origin/staging

Zapisz zmiany bez ich zatwierdzania

Czasami będziesz w trakcie jakiejś pracy, która nie jest jeszcze gotowa do wykonania, ale musisz zapisać jej stan. Właśnie tam przydaje się git stash. To polecenie przechowuje zmiany, usuwając je. Możesz je odzyskać, używając git stash pop. Jest jeszcze kilka poleceń, które sprawiają, że skrytka jest przydatna, ale to są te dwa, których używam regularnie.

Wyciągnij określony Git Commit

Czasami musisz wprowadzić konkretne zatwierdzenie do swojej bieżącej pracy. Z czystym HEAD (nie dokonałeś jeszcze żadnych zmian) możesz pobrać konkretny commit za pomocą git cherry-pick . Pełną dokumentację dotyczącą git cherry-pick znajdziesz tutaj.

Dla każdego zatwierdzenia Git tworzy długą sekwencję liter i cyfr, która jest nazywana Obiektem Git i powszechnie określana jako SHA. Ponieważ każdy zatwierdzenie otrzymuje jeden, możesz odwołać się do zatwierdzenia za pomocą jego wartości SHA. Przeczytaj więcej o obiektach Git.

Wyrzuć zmiany, których nie potrzebujesz

W pewnym momencie w każdym projekcie wprowadzimy zmiany, a potem zdamy sobie sprawę, że to nie działa i musimy je po prostu wyrzucić i zacząć od nowa. Zamiast próbować cofnąć, dopóki nie wrócimy tam, gdzie chcemy, możemy użyć następującego polecenia Git, aby usunąć wszelkie zmiany, które nie zostały jeszcze prześledzone.

git reset --hard

Powyższe polecenie zresetuje twój kod z powrotem do ostatniego zatwierdzenia w gałęzi, nad którą aktualnie pracujesz. Moglibyśmy również użyć <#commitSHA> z tym poleceniem, aby zresetować do określonego zatwierdzenia, jeśli chcielibyśmy wrócić do stanu sprzed ostatniego zatwierdzenia. Być może użyjesz tego do zresetowania do początkowego kasowania gałęzi, ponieważ cała praca warta całej gałęzi nie jest czymś, co chcesz zachować, ale część pracy już prześledziłeś.

Aby pójść o krok dalej, możemy wyrzucić wszystkie pliki lub katalogi, które nie były jeszcze śledzone w git za pomocą polecenia git clean.

git clean -fd: flagi f i d mówią gitowi, aby wyrzucił pliki i katalogi, które nie są śledzone.

Usuń gałęzie

Co tydzień lub dwa patrzę na wyniki polecenia git status i stwierdzam, że mam zbyt wiele gałęzi, aby rozsądnie zrozumieć, co się dzieje w moim repozytorium. Oznacza to, że mogę usunąć wszystkie gałęzie odpowiadające biletom, które zostały rozwiązane za pomocą następujących poleceń.

# usuwa lokalną wersję

git branch -d $nazwa oddziału

#usuwa gałąź na moim pilocie

git push $remotename --delete $nazwa gałęzi

Użyj kontroli wersji

Chociaż możesz nie być ekspertem we wszystkich poleceniach Git, których będziesz używać, jedną ważną rzeczą do zapamiętania jest to, że powinieneś używać kontroli wersji . Nawet jeśli jesteś jedyną osobą pracującą nad projektem, korzystanie z Git i przepływu pracy Git pomoże Ci zorganizować projekty. Nie będziesz musiał naciskać CTRL + Z, dopóki nie zresetujesz swojej pracy po napisaniu kodu, który nie działał.

Będziesz mógł zaufać swojemu systemowi i nadal produkować pracę dla swoich projektów.

Wypróbuj w pełni zarządzany hosting WordPress

Potrzebujesz hostingu zoptymalizowanego pod WordPress? Już dziś sprawdź w pełni zarządzane plany hostingowe WordPress firmy Nexcess.