5 Git workflows and branching strategy you can use to improve your development process
Nie spotkałem dewelopera, który patrząc na wiadomość o konflikcie nie wyrywał sobie włosów z głowy z powodu frustracji.
Próbowanie rozwiązania każdego konfliktu scalania jest jedną z tych rzeczy, których każdy deweloper nienawidzi. Zwłaszcza, gdy pojawia się on w momencie, gdy szykujesz się do wdrożenia produkcyjnego!
To właśnie tutaj posiadanie odpowiedniego przepływu pracy Git może zrobić wiele dobrego dla Twojego przepływu pracy.
Oczywiście, posiadanie odpowiedniego przepływu pracy git nie rozwiąże wszystkich problemów. Ale jest to krok w dobrym kierunku. W końcu, z każdym zespołem pracującym zdalnie, potrzeba wspólnego budowania funkcji bez zakłócania pracy bazy kodu jest krytyczna.
Jak go skonfigurować zależy od projektu, nad którym pracujesz, harmonogramu wydań, wielkości zespołu i nie tylko!
W tym artykule przeprowadzimy Cię przez 5 różnych przepływów pracy git, ich zalety, wady i kiedy powinieneś ich używać. Wskakujmy!
Podstawowy przepływ pracy Git
Najprostszym przepływem pracy git jest ten, w którym istnieje tylko jedna gałąź – gałąź główna. Deweloperzy commitują bezpośrednio do niej i używają jej do wdrażania do środowiska staging i produkcyjnego.
Ten przepływ pracy nie jest zwykle zalecany, chyba że pracujesz nad projektem pobocznym i chcesz szybko zacząć.
Ponieważ jest tylko jedna gałąź, nie ma tu żadnego procesu. To sprawia, że rozpoczęcie pracy z Gitem nie wymaga wysiłku. Jednak niektóre wady, o których należy pamiętać przy korzystaniu z tego przepływu pracy to:
- Współpraca nad kodem doprowadzi do wielu konfliktów.
- Możliwość wysłania błędnego oprogramowania na produkcję jest większa.
- Utrzymanie czystego kodu jest trudniejsze.
Git Feature Branch Workflow
Obieg Git Feature Branch staje się niezbędny, gdy nad tą samą bazą pracuje więcej niż jeden programista.
Wyobraź sobie, że jeden programista pracuje nad nową funkcjonalnością. A drugi programista pracuje nad drugą funkcjonalnością. Teraz, jeśli obaj deweloperzy pracują nad tą samą gałęzią i dodają do niej commit’y, sprawiłoby to, że w bazie danych zapanowałby ogromny bałagan z mnóstwem konfliktów.
Aby tego uniknąć, dwaj deweloperzy mogą stworzyć dwie oddzielne gałęzie z gałęzi głównej i pracować nad swoimi funkcjami indywidualnie. Kiedy skończą swoją funkcję, mogą połączyć swoją gałąź z główną i wdrożyć ją bez konieczności czekania na ukończenie drugiej funkcji.
Zaletą tego przepływu pracy jest to, że git feature branch pozwala na współpracę nad kodem bez konieczności martwienia się o konflikty kodu.
Git Feature Workflow z gałęzią Develop
Ten przepływ pracy jest jednym z bardziej popularnych przepływów pracy wśród zespołów programistów. Jest on podobny do przepływu Git Feature Branch z gałęzią deweloperską, która jest dodawana równolegle do gałęzi głównej.
W tym przepływie pracy, gałąź główna zawsze odzwierciedla stan gotowy do produkcji. Za każdym razem, gdy zespół chce wdrożyć produkt na produkcję, wdraża go z gałęzi master.
Gałąź deweloperska odzwierciedla stan z najnowszymi zmianami rozwojowymi dla następnego wydania. Deweloperzy tworzą gałęzie z gałęzi deweloperskiej i pracują nad nowymi funkcjami. Kiedy funkcjonalność jest już gotowa, jest testowana, łączona z gałęzią developerską, testowana z kodem z gałęzi developerskiej w przypadku wcześniejszego scalenia, a następnie łączona z gałęzią master.
Zaletą tego przepływu pracy jest to, że pozwala zespołom konsekwentnie scalać nowe cechy, testować je w staging i wdrażać na produkcję. Podczas gdy utrzymanie kodu jest łatwiejsze, może stać się nieco męczące dla niektórych zespołów, ponieważ może czuć się jak przechodzenie przez żmudny proces.
Przepływ pracy gitflow
Przepływ pracy gitflow jest bardzo podobny do poprzedniego przepływu pracy, który omówiliśmy w połączeniu z dwoma innymi gałęziami – gałęzią wydania i gałęzią hot-fix.
Gałąź hot-fix
Gałąź hot-fix jest jedyną gałęzią, która jest tworzona z gałęzi master i bezpośrednio scalana z gałęzią master zamiast z gałęzią develop. Jest ona używana tylko wtedy, gdy musisz szybko załatać problem produkcyjny. Zaletą tej gałęzi jest to, że pozwala ona na szybkie wdrożenie problemu produkcyjnego bez zakłócania pracy innych osób lub bez konieczności czekania na następny cykl wydania.
Po tym jak poprawka zostanie połączona z gałęzią master i wdrożona, powinna zostać połączona zarówno z gałęzią developerską jak i bieżącą gałęzią wydania. Robi się to po to, aby zapewnić, że każdy kto rozwidla się z gałęzi develop, aby stworzyć nową gałąź z nowymi funkcjami, ma najnowszy kod.
Gałąź release
Gałąź release jest rozwidlana z gałęzi develop po tym, jak gałąź develop ma wszystkie funkcje zaplanowane dla wydania, które zostały pomyślnie do niej wcielone.
Żaden kod związany z nowymi funkcjami nie jest dodawany do gałęzi release. Tylko kod, który odnosi się do wydania jest dodawany do gałęzi wydania. Na przykład dokumentacja, poprawki błędów i inne zadania związane z tym wydaniem są dodawane do tej gałęzi.
Po połączeniu tej gałęzi z master i wdrożeniu jej na produkcję, jest ona również scalana z powrotem do gałęzi develop, tak że gdy nowa funkcjonalność zostanie rozwidlona z develop, będzie miała najnowszy kod.
Ten przepływ pracy został po raz pierwszy opublikowany i spopularyzowany przez Vincenta Driessena i od tego czasu jest szeroko stosowany przez organizacje, które mają zaplanowany cykl wydawniczy.
Ponieważ git-flow jest opakowaniem wokół Gita, możesz zainstalować git-flow w swoim obecnym repozytorium. Jest to prosty proces i nie zmienia niczego w repozytorium, poza tworzeniem gałęzi dla użytkownika.
Aby zainstalować na komputerze Mac, wykonaj brew install git-flow w swoim terminalu.
Aby zainstalować na komputerze Windows, musisz pobrać i zainstalować git-flow. Po zakończeniu instalacji, uruchom następujące polecenie Git git flow init aby użyć go w swoim projekcie.
Git Fork Workflow
Przepływ Fork jest popularny wśród zespołów, które używają oprogramowania open-source.
Przepływ zazwyczaj wygląda tak:
- Deweloper rozwidla oficjalne repozytorium oprogramowania open-source. Kopia tego repozytorium jest tworzona na ich koncie.
- Deweloper następnie klonuje repozytorium ze swojego konta na swój lokalny system.
- Zdalna ścieżka do oficjalnego repozytorium jest dodawana do repozytorium, które jest klonowane na lokalny system.
- Deweloper tworzy nową gałąź funkcji w swoim lokalnym systemie, wprowadza zmiany i je zatwierdza.
- Te zmiany wraz z gałęzią są wypychane do kopii repozytorium dewelopera na jego koncie.
- Prośba o ściągnięcie z oddziału jest otwierana do oficjalnego repozytorium.
- Menadżer oficjalnego repozytorium sprawdza zmiany i zatwierdza je do połączenia z oficjalnym repozytorium.
Automatyzacja przepływu pracy Git i strategii rozgałęziania dla lepszej produktywności
Jedną z rzeczy, którymi deweloperzy muszą nieustannie żonglować, jest aktualizowanie narzędzia do zarządzania projektami, aby ich koledzy z zespołu byli na bieżąco. Dlatego w Zepel, nasi programiści automatyzują swój przepływ pracy, dzięki czemu mogą poświęcić więcej czasu na budowanie oprogramowania.
Oto jak zautomatyzowaliśmy nasz przepływ pracy w git, aby wszyscy byli zsynchronizowani:
Pomimo, że Zepel integruje się głęboko z GitHubem, Bitbucketem i GitLabem, my używamy GitHuba wewnętrznie. Tak więc, gdy już zintegrujemy GitHub z Zepelem, nasz zespół programistów konfiguruje automatyzację git workflow w Zepelu. Oto jak to wygląda dzisiaj:
Kiedy programiści robią postępy, nasz zespół automatycznie otrzymuje powiadomienie ze Slacka, a ich zmiany są rejestrowane w historii użytkownika.
Twój własny przepływ pracy i strategia rozgałęziania Git!
Przepływy pracy git, które pokazałem w tym artykule, są przykładami niektórych popularnych i najlepiej działających przepływów pracy dla zespołu programistów. Niektóre zespoły tworzą gałąź dla Staging i działa to dla nich idealnie.
Jeśli używasz innych przepływów pracy, które działają dobrze dla Ciebie, tweetnij do nas @getzepel. Chętnie je zaprezentujemy!
Pomocne artykuły
Vikash KoushikThe Zepel Blog 
Ranjali RoyThe Zepel Blog 
Ranjali RoyThe Zepel Blog 