Jakie są wady i zalety Git-Flow i Github-Flow? [Zamknięte]


125

Niedawno zaczęliśmy korzystać z GitLab.

Obecnie używam „scentralizowanego” przepływu pracy.

Rozważamy przejście na github-flow, ale chcę się upewnić.

Jakie są wady i zalety Git-Flow i Github-Flow ?

Odpowiedzi:


133

Jak omówiono w 17 odcinku GitMinutes, Nicholas Zakas w swoim artykule na temat „ Przepływy pracy GitHub wewnątrz firmy ”:

Git-flow to proces zarządzania zmianami w Git, który został stworzony przez Vincenta Driessena i towarzyszy mu kilka rozszerzeń Git do zarządzania tym przepływem.
Ogólną ideą git-flow jest mieć kilka oddzielnych oddziałów, które zawsze istnieją, każdy w innym celu: master, develop, feature, release, i hotfix.
Proces tworzenia funkcji lub błędów przechodzi z jednej gałęzi do drugiej, zanim zostanie ostatecznie wydana.

Niektórzy respondenci wskazali, że używają git-floww ogóle.
Niektórzy zaczęli git-flowi odeszli od niego.

Głównym powodem odejścia jest to, że git-flowproces ten jest trudny do wykonania w modelu ciągłego (lub prawie ciągłego) wdrażania.
Ogólne wrażenie jest takie, że git-flowdziała dobrze w przypadku produktów w bardziej tradycyjnym modelu wydawania, w którym publikacje są wydawane raz na kilka tygodni, ale proces ten znacznie się psuje, gdy publikujesz je raz dziennie lub częściej .

W skrócie:

Zacznij od modelu tak prostego, jak to tylko możliwe (jak zwykle w przypadku przepływu GitHub) i przejdź do bardziej złożonego modelu, jeśli zajdzie taka potrzeba.


Możesz zobaczyć interesującą ilustrację prostego przepływu pracy opartego na GitHub-Flow pod adresem:
Prosty model rozgałęzienia git ”, którego głównymi elementami są:

  1. master musi być zawsze możliwe do rozmieszczenia.
  2. wszystkie zmiany dokonane za pośrednictwem gałęzi funkcji (żądanie ściągnięcia + scalanie)
  3. rebase w celu uniknięcia / rozwiązania konfliktów; połączyć się zmaster

https://a248.e.akamai.net/camo.github.com/9783623eba280ba5ace8b9e63842be52af2f0546/687474703a2f2f7374617469632e62656e65742e61692f736b697463682f666c6f772d323031331330e


Aby uzyskać bardziej kompletny i niezawodny przepływ pracy, zobacz gitworkflow (jedno słowo) .


88

Nie ma przepływu pracy, w którym każdy powinien się kierować, ponieważ wszystkie modele są nieoptymalne. Powiedziawszy to, możesz wybrać odpowiedni model dla swojego oprogramowania na podstawie poniższych punktów;

Wiele wersji w produkcji - użyj Git-flow

Jeśli Twój kod ma wiele wersji w produkcji (np. Typowe produkty programowe, takie jak systemy operacyjne, pakiety biurowe, aplikacje niestandardowe itp.), Możesz użyć git-flow. Głównym powodem jest to, że podczas opracowywania następnej wersji musisz stale wspierać poprzednie wersje w produkcji.

Pojedyncza wersja w produkcyjnym prostym oprogramowaniu - użyj Github-flow

Jeśli Twój kod ma tylko jedną wersję produkcyjną przez cały czas (tj. Strony internetowe, usługi internetowe itp.), Możesz użyć github-flow. Głównym powodem jest to, że nie musisz robić skomplikowanych rzeczy dla programisty. Gdy programista ukończy funkcję lub naprawi błąd, zostanie natychmiast przeniesiony do wersji produkcyjnej.

Pojedyncza wersja w produkcji, ale bardzo złożone oprogramowanie - użyj Gitlab-flow

W przypadku dużego oprogramowania, takiego jak Facebook i Gmail, może być konieczne wprowadzenie gałęzi wdrażania między oddziałem a oddziałem głównym, w którym mogłyby działać narzędzia CI / CD>, zanim trafi do produkcji. Chodzi o to, aby do wersji produkcyjnej wprowadzić większe zabezpieczenia, ponieważ są używane przez miliony ludzi.


7
Wystarczy dodać „Gitdmz-flow” / „Git DMZ Flow” do listy: gist.github.com/djspiewak/9f2f91085607a4859a66
Robert Fey

1
Wymienione firmy używają systemu opartego na magistrali. paulhammant.com/2014/01/08/...
PatrickWalker

1
Przepływ Git DMZ jest bardziej podobny do Gitflow, a gałąź DMZ jest jak gałąź deweloperska. Dlatego nie czuję w tym nic specjalnego.
Gayan Pathirage

2
Z mojego zrozumienia Git-Flow nie działa dobrze z wersjami wieloprodukcyjnymi. Strategia poprawek zakłada, że ​​masz tylko jedną wersję produkcyjną i robisz poprawkę w odpowiedniej gałęzi wydania (a później scalasz ją z powrotem do gałęzi deweloperskiej). Wygląda na to, że nie wyjaśnia, jak można naprawić jeden błąd, który istnieje w wielu gałęziach produkcyjnych.
Adrian Shum

5
@GayanPathirage Właściwie tak nie jest. 1. „klasyczne” znaczniki GitFlow na serwerze głównym. Gałąź poprawek jest przeznaczona tylko dla Ciebie, aby naprawić najnowszą wersję produkcyjną (z master). 2. „gałąź wydania” oznacza coś innego w Gitflow, która w rzeczywistości jest przedpremierową gałęzią podglądu (rozgałęzia się z gałęzi deweloperskiej i ma na celu scalenie do mastera, gdy zostanie naprawdę wydana). 3. To, o czym mówisz, to coś, co nazywa się „gałęzią wsparcia” w GitFlow (jest to jeden z powodów, dla których nie lubię GitFlow: niekonwencjonalna terminologia). Jednak nadal jest to przepływ eksperymentalny (więc nie widać go w większości wstępów do Gitflow)
Adrian Shum,

38

Używam modelu git-flow od ponad roku i jest w porządku.

Ale to naprawdę zależy od tego, jak Twoja aplikacja zostanie opracowana i wdrożona.

Działa dobrze, gdy masz aplikację, która ma powolny przepływ programowania / wdrażania.

Ale na przykład tak jak GitHub mamy aplikację, która ma szybki przepływ rozwoju / wdrażania, wdrażamy codziennie, a czasem kilka razy dziennie, w tym przypadku git-flow ma tendencję do spowolnienia wszystkiego moim zdaniem, a ja używam GitHub pływ.

Inną rzeczą do rozważenia jest to, że git-flow nie jest standardowym gitem, więc możesz, a kiedy powiem, że możesz, naprawdę mam na myśli, że znajdziesz programistów, którzy tego nie wiedzą, a potem jest krzywa uczenia się, więcej szansa na zepsucie rzeczy. Jak wspomniano powyżej, ktoś opracował zestaw skryptów, aby ułatwić korzystanie z git-flow, więc nie musisz pamiętać wszystkich poleceń, pomoże ci on przy poleceniach, ale zapamiętywanie faktycznego przepływu jest twoją pracą , Spotykałem się więcej niż raz, kiedy programista nie wiedział, czy to poprawka, czy funkcja, a nawet gorzej, gdy nie pamiętają przepływu i rzeczy.

Istnieje co najmniej jeden interfejs graficzny obsługujący git-flow dla komputerów Mac i Windows SourceTree .

Obecnie skłaniam się bardziej w stronę przepływu GitHub, ze względu na jego prostotę i łatwość zarządzania. Ponadto z powodu „częstego wdrażania wczesnego wdrażania” ...

Mam nadzieję że to pomoże


+1. Zgadzam się z Tobą.
VonC

2
Przepływ GitHub znajduje się w Git-Flow. Pomyśl, jeśli potrzebujesz ciągłej integracji i ciągłego wdrażania, możesz po prostu uruchomić jak najwięcej z rozwijaniem gałęzi. Każda funkcja jest rozgałęziona z gałęzi deweloperskiej. Możesz nie potrzebować gałęzi głównej lub gałęzi wydania, chyba że masz złożone modele wdrażania. (np. Twoja wersja 1.1 jest aktywna na jakimś kliencie, twoja 1.2 jest aktywna na innym kliencie, a obecnie tworzysz 1.3 dla swojego nowego klienta) Wszyscy trzej klienci będą prosić o poprawki błędów i zmiany w ich odpowiedniej wersji.
Gayan Pathirage

Witam Diego i dziękuję za odpowiedź. A co z obsługą wielu wersji? Czy robisz to łatwo z Git Flow? Słyszałem, że jest to trudne, ponieważ potrzebujesz oddziałów wsparcia! Czy uważasz, że model dobrze się do tego nadaje?
Luis Gouveia

1
Cześć Luis, myślę, że możesz sprawić, by model działał, ale znowu czuję, że możesz osiągnąć to samo za pomocą standardowego przepływu pracy git.
Diego Antunes

1
@LuisGouveia, ponieważ Twoje pytanie i moja odpowiedź powyżej, natknąłem się na projekt, w którym git-flow będzie działał idealnie i jestem właścicielem projektu. Chodzi o to, aby git flow release...w połączeniu z akcjami github wdrożyć aplikację. W mojej oryginalnej odpowiedzi wspomniałem, że publikowaliśmy wiele razy dziennie, co powodowało problemy podczas korzystania z git-flow. Powodem, dla którego myślę, że git-flow będzie dobrze działał w tym projekcie, jest to, że mamy wstępnie zdefiniowany cykl wydawniczy, który jest jednym z głównych punktów sprzedaży przy korzystaniu z git-flow.
Diego Antunes
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.