Strategia gałęzi Git dla małego zespołu deweloperów [zamknięte]

Mamy aplikację internetową, którą aktualizujemy i wypuszczamy prawie codziennie. Używamy git jako naszego VCS, a nasza obecna strategia rozgałęziania jest bardzo prosta i zepsuta: mamy gałąź główną i sprawdzamy zmiany, w których „czujemy się dobrze”. To działa, ale tylko do momentu sprawdzenia zmiany.

Czy ktoś ma ulubioną strategię oddziału git dla małych zespołów, która spełnia następujące wymagania:

1. Działa dobrze dla zespołów od 2 do 3 programistów
2. Lekki i niezbyt duży proces
3. Pozwala deweloperom z łatwością izolować pracę nad poprawkami błędów i większymi funkcjami
4. Pozwala nam utrzymać stabilny oddział (w tych chwilach, kiedy musimy uruchomić nasze serwery produkcyjne)

Idealnie, chciałbym zobaczyć twój proces krok po kroku dla programisty pracującego nad nowym błędem

Możesz skorzystać z przepływu pracy, który Scott Chacon opisuje w Pro Git . W tym przepływie pracy masz dwie gałęzie, które zawsze istnieją, opanowują i rozwijają się .

master reprezentuje najbardziej stabilną wersję twojego projektu i zawsze wdrażasz do produkcji z tego oddziału.

develop zawiera zmiany, które są w toku i niekoniecznie muszą być gotowe do produkcji.

Z rozwinięcia gałęzi, tworzenie tematycznych oddziałów do pracy na poszczególnych funkcji i poprawek. Gdy twoja funkcja / poprawka jest gotowa do użycia, łączysz ją w programowanie , w którym to momencie możesz przetestować, w jaki sposób współdziała ona z innymi gałęziami tematycznymi, w które włączyli się twoi współpracownicy. Gdy programowanie jest w stanie stabilnym, scal je w master . Wdrożenie do produkcji z poziomu głównego powinno zawsze być bezpieczne .

Scott opisuje te długo działające gałęzie jako „silosy” kodu, gdzie kod w mniej stabilnej gałęzi ostatecznie „przejdzie” do jednej uznanej za bardziej stabilną po przetestowaniu i ogólnej akceptacji przez zespół.

Krok po kroku przepływ pracy w tym modelu może wyglądać następująco:

1. Musisz naprawić błąd.
2. Utworzyć oddział o nazwie myfix , który jest oparty na rozwoju branży.
3. Pracuj nad błędem w tej gałęzi tematu, aż zostanie naprawiony.
4. Scal myfix w celu opracowania . Przeprowadź testy.
5. Odkrywasz swoje konflikty poprawek z inną poprawką do gałęzi tematycznej, do której Twój współpracownik połączył się w rozwijanie podczas pracy nad poprawką.
6. Wprowadź więcej zmian w gałęzi myfix, aby poradzić sobie z tymi konfliktami.
7. Merge myfix do rozwoju i prowadzonych badań ponownie.
8. Wszystko dziala. Scalanie rozwija się w mistrza .
9. Wdrożyć do produkcji od mistrza w dowolnym momencie, ponieważ wiesz, że jest stabilny.

Aby uzyskać więcej informacji na temat tego przepływu pracy, zobacz rozdział Rozgałęzienia przepływu pracy w Pro Git.

Po przybyciu jako nowicjusz próbuje znaleźć prostą strategię nauczania innym deweloperom, którzy nigdy nie korzystali z kontroli źródła. Jest to ten, który pasuje do http://nvie.com/posts/a-successful-git-branching-model/ Próbowałem użyć standardowego przepływu pracy GIT, który znajduje się na stronach podręcznika, ale nieco mnie zdezorientowało i moich odbiorców.

W ciągu ostatnich 6 miesięcy musiałem naprawiać konflikty tylko dwa razy. Dodałem kroki, aby zawsze testować po scaleniu i często „pobierać i łączyć” lub „ściągać --rebase” (raz rano i popołudniu) podczas opracowywania funkcji. Użyliśmy również github.com jako centralnego miejsca do pobrania najnowszego kodu.

(Mój komentarz powyżej jest własną odpowiedzią, jak powinienem był początkowo.)

Od Scott Chacon z Github:

Jak to robimy? Czym jest GitHub Flow?

• Wszystko w gałęzi master jest możliwe do wdrożenia
• Aby pracować nad czymś nowym, utwórz opisowo odgałęzioną gałąź master (tj .: new-oauth2-scopes)
• Zaangażuj się w tę gałąź lokalnie i regularnie wypychaj swoją pracę do tej samej gałęzi o nazwie na serwerze
• Jeśli potrzebujesz informacji zwrotnej lub pomocy lub uważasz, że oddział jest gotowy do scalenia, otwórz żądanie ściągnięcia
• Po sprawdzeniu i wylogowaniu się przez użytkownika z funkcji możesz połączyć ją w master
• Po scaleniu i przekazaniu do „master”, możesz i powinieneś natychmiast wdrożyć

Zobacz cały artykuł, aby uzyskać więcej informacji: http://scottchacon.com/2011/08/31/github-flow.html

Zauważ, że „żądania ściągania” są wynalazkiem Github i jest to coś, co wypiekło się na ich stronie internetowej, a nie w samej Git: https://help.github.com/articles/using-pull-requests/

Używaj mastergałęzi jako gałęzi programistycznej i twórz gałęzie wersji do wykonywania poprawek błędów.

Wszelkie nowe funkcje pojawią się masterw oknie programowania (zatwierdzone bezpośrednio lub jako gałęzie tematów z żądaniami ściągania, zależnie od Ciebie - nie pokazane graficznie). Po wdrożeniu wszystkich zaplanowanych funkcji, wprowadź funkcję zamrażania funkcji i przeprowadź testy. Kiedy będziesz zadowolony, oznacz wydanie masterjako v1.0.

Z czasem użytkownicy znajdą błędy, v1.0więc będziesz chciał utworzyć gałąź z tego tagu (np. Nazwać ją po wydaniu 1.0) i naprawić te błędy w gałęzi. Kiedy masz już wystarczającą liczbę poprawionych błędów, które Twoim zdaniem wymagają wydania nowego wydania, oznacz je jako v1.0.1i połącz z powrotem master.

Tymczasem w mastergałęzi może pojawić się nowe okno programowania, które ostatecznie zostanie oznaczone jako v1.1.

Opłucz i powtórz.

Jest to zgodne z logiką numeracji wersjonowania semantycznego .

 ---------(v1.0)--------------------------------(v1.1)-----------------------------> master
             \                                     \  
              ---(v1.0.1)---(v1.0.2)---> 1.0        ---(v1.1.1)---(v1.1.2)---> 1.1

W VCS posiadanie tylko gałęzi „master” szybko pokazuje swoje ograniczenia, ponieważ nie można wykonywać wszystkich prac programistycznych jednocześnie w jednym oddziale.
Oznacza to, że musisz wiedzieć, kiedy się rozgałęzić .

Ale w DVCS (jak w „zdecentralizowanym” VCS) masz również problem z publikacją z , z gałęziami, które trzymasz lokalnie w swoich repozytoriach, i gałęziami, do których pchasz lub z których wyciągasz.

W tym kontekście zacznij od określenia współbieżnych prac programistycznych i zdecyduj o procesie publikacji (push / pull). Na przykład (i to nie jedyny sposób):

• prod jest gałęzią publiczną tylko do odczytu z produkcyjnym kodem. Każdy może z niego skorzystać, aby:
  • oprzeć na nim swój obecny rozwój (do testów lokalnych lub do zintegrowania w lokalnym repozytorium deweloperów poprawkę wykonaną w rep rep w gałęzi prod)
  • rozgałęzienie w celu wykonania nowych funkcji (ze znanego stabilnego kodu)
  • gałąź, aby rozpocząć kolejną gałąź wydania (ta, która ma być produkowana)
    nikt nie powinien naciskać bezpośrednio na prod (stąd tylko do odczytu)
• release jest gałęzią konsolidacji odczytu i zapisu, w której odpowiednie zatwierdzenia są wybierane jako część następnego wydania.
  Każdy może naciskać na wydanie, aby zaktualizować następne wydanie.
  Każdy może wycofać się ze wspomnianego wydania, aby zaktualizować swój proces konsolidacji lokalnej.
• FeatureX jest prywatną gałęzią do odczytu i zapisu (w tym sensie, że nie musi być wypychany do centralnego repozytorium produktów) i może być wypychany / przenoszony pomiędzy repozytoriami dev. Reprezentuje wysiłek średnio- i długoterminowy, różny od codziennego twórcy
• master reprezentuje aktualnego programistę i jest wpychany / przeciągany między repozytoriami programistów.

Istnieją inne procesy zarządzania wersjami, jak potwierdza to pytanie SO .

Przeczytaj tutaj Git Workflow ReinH dla zespołów Agile: http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

Działa to bardzo dobrze w przypadku małych zespołów. Celem jest upewnienie się, że wszystko, co może być potencjalnie niestabilne, trafi do jakiejś gałęzi. Scalanie z powrotem do wzorca tylko wtedy, gdy jesteś gotowy, aby wszyscy pracujący poza gałęzią funkcji mogli z niego korzystać.

Uwaga: ta strategia nie jest specyficzna dla git, ale git sprawia, że ​​jej implementacja jest dość łatwa.