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.

[smentek]

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ć.

Ja pracuje w ten sposób:

Jeżeli widzę ralną potrzebę tworzenia nowego brancha to go tworzę. Kiedy ta potrzeba znika to znika też sam branch ponieważ go usuwam. Uprzednio wmergowując zmiany do lokalnego master jeżeli jestem zadowolony z tego co zrobiłem lub po prostu je porzucam. Wszystko to lokalnie. Kiedy jestem pewien ze mój master jest w miarę stabilny pushuje go do origin. Ten push jest momentem w ktorym staram sie przetestowac zmiany tak aby nie upublicznic bledow. Jezeli master osiaga punkt, który jest jakas stabilna lub koncowa wersje produktu to oznaczam to np. nadajac mu taga. I tyle, to wystarczy nawet na sporych rozmiarow projekt.

Jezeli jest tak ze chce sie podzielic kotryms z moich lokalnych branchy developerskich powiedzmy "branchX" bo np. potrzebuje aby jakis programista mi w czyms pomogl to upubliczniam (push) go na swoim zdalnym serwerze git ale nie pod doemna origin projektu! Gosc sciaga (pull) moj kod robi w nim zniamy i wystawia go (push) na wlasnym zdalnym serwerze (znowu nie na serwerze projektu). Taka wymiana moze isc wiele razy. Kiedy skonczymy to wmergowuje jego ostatnie zmiany (pull) w swoje lokalny branchX. i dalej leci ja wyzej czyli z lokalnego branchX do lokalnego master, lokalny master push do master na origin i wywalam lokalny branchX jako niepotrzebne.

Nie ma takiej opcji aby pogubić się w branchach poniewaz one nie istnieją "wszystkie na raz" a pojawiaja sie i ZNIKAJĄ wmiare potrzeby i nie jest ich wiele. Opis do ktorego link podales moim zdaniem NIE jest dobry choć graficznie bardzo mi się podoba . Przedstawiona tam koncepcja moze byc uzyteczna ale bradziej pasuje do SVN i innych systemów nierozproszonych skąd zreszta została wzięta. W tych systemach tworzenie branchy develop i master (trunk) ma sens z wielu powodow. W SVN każdy commit równa się upublicznieniem zmian tak więc jeżeli czesto komitujesz (a to dobra praktyka) to robiac to bezposrednio do trunk mozesz latwo wyprowadzic go ze stabilnosci przez co inni uczestnicy projektu zamiast pracowac potykaja sie o twoje błedy.

W GIT nie ma takiego problemu komity ida tylko na twoj lokalny host. Mozna powiedzic ze gitowy lokalny master jest tym czym SVNowy branch dev. Wiec nie ma realnej potrzeby brancha dev na serwerze origin. W praktyce w projektach na GIT branch dev istnieje tylko z uwagi na programistów którzy nie potrafią przestawić starych nawyków i łatwiej jest zrobić im ten brach niż się z nimi użerać...

Ten post edytował smentek 15.02.2011, 23:59:09

[melkorm]

Jeżeli chodzi o mniejsze rzeczy gdzie bugfix'y/zmiany robi się real-time to moim zdaniem najlepiej rozbić to na dev / stable (lub nawet ominąć dev jeżeli korzystasz sam z tego repo) i tylko branchować jakieś większe rzeczy, lub rzeczy które mogą zająć więcej czasu / testów a w międzyczasie może dojść jakaś nowa poprawka, wtedy wystarczy przełączyć się na stable/dev i ją zrobić i wrócić do dalszej pracy nad gałęzią.

[athabus]

Ja akurat wykorzystuje gita do małych projektów pisanych w pojedynkę. Ogólnie w zależności od podejścia mam 1 lub 2 gałęzie "stałe". Origin + Dev. Do KAŻDEJ poprawki tworzę gałąź jeśli tylko zakładam, że zajmie mi ona więcej niż 5 minut. Powód u mnie jest prosty - zawsze może wyniknąć coś, co oderwie mnie od pracy i nie ukończę od ręki pracy, potem może zajść potrzeba zmiany w innym miejscu i jest problem. Zaobserwowałem taką prawidłowość, że zawsze jak nie mam utworzonej gałęzi do jakiegoś topicu, to w trakcie pracy nad nim wynika jakaś pilna sprawa ;-)

W git praca z gałęziami jest banalnie prosta i wg. instrukcji obsługi praktycznie nic nie kosztuje, dlatego korzystam z nich bardzo często. Zdarza mi się utworzyć 5-10 gałęzi dziennie w obrębie projektu nad którym pracuję.

Ogólnie moja koncepcja pracy jest taka jak tutaj.

Co do dużych projektów niestety nie mam doświadczenia, więc nie będę się wypowiadał.

[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)