Modele pracy z Gitem, Konwencje, praktyki, plusy i minusy Opcje

[Zyx]

Skoro już powstał stosowny ku temu dział, warto poruszyć temat modeli pracy z Gitem. Wiadomo, w tym systemie kontroli wersji nacisk kładziony jest na tworzenie gigantycznej liczby gałęzi i ich scalanie. Gdy wiosną przerzuciłem się na Gita, wszystko było fajnie, z wyjątkiem tego, że nie miałem żadnego doświadczenia w tym, jak organizować te gałęzie, by się w nich nie pogubić.

Dopiero niedawno problem de facto się rozwiązał, gdy znajomy podesłał mi opis pewnego modelu pracy z Gitem:

http://nvie.com/posts/a-successful-git-branching-model/

Czy ktoś z Was już go stosuje i mógłby podzielić się doświadczeniami? A może wykorzystujecie jakieś inne, własne i sprawdzone konwencje? Mi powyższy model wygląda na dobry do większych projektów, natomiast ostatnio Gita używam coraz częściej do różnych mniejszych prac, nawet na własne potrzeby, gdzie ciężko jest go zastosować choćby z tego powodu, że nie ma w nich "wydań" jako takich. Tu wciąż sprawa pozostaje otwarta.

[wookieb]

Model opisany w podanym linku jest bardzo dobry, wręcz wystarczający dla większości projektów.
Nie zgodziłbym się tylko ze zdaniem, że domyślnym parametrem dla "git merge" powinno być --no-ff .
W moim przypadku bardzo często zdarza się, że niektóre funkcjonalności rozwijam tylko ja. Tworzę dla nich lokalne branche i nie muszę wszystkich naokoło informować, że do tego celu utworzyłem sobie specjalne gałęzie bo co to kogo interesuje (Całkiem niedawno opisywałem przypadek z lokalnym branchami HG w temacie porównawczym SCM). Ale jeżeli chodzi o gałęzie rozwijane wspólnie to jak najbardziej fast-forward nie powinien występować.

Podsumowując, artykuł opisał większość ważnych rzeczy:
- gałąź deweloperską
- gałąź z RC
- gałąź tagów
- gałąź nowych funkcjonalności

Omówił jak i kiedy je używać. Moim zdaniem przykład bardzo bardzo dobry i większość programistów może się do niego z powodzeniem stosować.
I jeszcze mała rada dla wszystkich. Jeżeli prowadzicie projekt publiczny to prowadzenie tylko 1 brancha publicznego jest naprawdę dobrym rozwiązaniem. Od oznaczania wersji są TAGI, nie branche.
Dodatkowa gałąż typu "not-stable, bug-tracker-response" może być ale tagi w niej też są świetnym rozwiązaniem (nawet oznaczane numerami zgłoszeń z bug-trackera)