Git i praca zespołowa

0

Witam,
mam pytanie do doświadczonych w temacie. Mam dylemat, jak używać git-a w pracy grupowej. Każdy z członków zespołu ma przydzielone zadanie. Jak je zrealizuje bierze się za następne. Czy powinien tworzyć branch osobno dla każdego zadania i po jego zakończeniu mergować do głównego? Czy może każdy developer powinien mieć swój branch i co jakiś czas (np. co ukończone zadanie) mergować swoje zmiany z masterem?

1

Nie. Powinna być jedna główna gałąź (master) i każdy feature powinien mieć otwieraną nową gałąź. Mergowaniem powinien się zająć project master, który jeśli będzie trzeba będzie nawet ślęczał i ręcznie robił cherry-picki. Gałęzie feature powinny być dodatkowo często przyrównywane (np. poprzez fast-forward) do głównej linii, by się nie okazało, że ktoś pracował nad funkcjonalnością, której się nie da włączyć, bo za dużo konfliktów narosło.

0

Dzięki zaodpowiedź. JEszcze jedno pytanko - czy po zakończeniu pracy nad featurem oraz zmergowaniu brancha do master - należy tego brancha skasować. Czy trzymać go do końca istnienia projektu? Jeżeli będziemy je trzymać to po jakimś czasie będzie sporo branchów i może się zacząć robić bałagan.

1

Sposobów używania git'a jest kilka.
Pierwszy jest tak jak napisałeś: feature = branch, który potem jest merge'owany do master
Drugi: feature = branch , który jest potem rebased do master
Trzeci (mój preferowany): feature = jeden commit do master. Feature tworzy się w osobnym branch'u z dowolną liczbą commit'ów, przed releasem do master, robi się merge master do feature (zauważ, że to jest inny niż zwyczajowy kierunek i powinno być to robione regularnie podoczas tworzenia feature'a). Następnie skaczesz do master git checkout master, robisz git checkout feature -- ("--" powoduje, że dalej jesteśmy w master, ale kod mamy z feature), a nastęonie robi się commit na master. W tej sytuacji historia robi się liniowa i maksymalnie czysta: jest pozbawiona bezsensownych commit'ów, typu poprawa literówki itp.
Jak jest więcej ludzi, to zdecydowanie musi być człowiek odpowiedzialny za merge feature'ów "project master", ale jeśli ludzi jest mało (<=5) to nie jest to konieczne.

1
gier0 napisał(a):

Dzięki zaodpowiedź. JEszcze jedno pytanko - czy po zakończeniu pracy nad featurem oraz zmergowaniu brancha do master - należy tego brancha skasować. Czy trzymać go do końca istnienia projektu? Jeżeli będziemy je trzymać to po jakimś czasie będzie sporo branchów i może się zacząć robić bałagan.

Jeśli feature jest zakończony nie ma sensu trzymać takiego brancha. Poza tym na remote powinny się znaleźć tylko te branche, które już są w dość zaawansowanym stopniu i są przygotowywane do merge z master, inne mają być tylko lokalnie u danego developera (chyba, że pracują we 2, ale wtedy mogą zrobić sobie dodatkowy fork i na nim pracować).

0

W przypadku gdy każdy może mergować z masterem, wówczas dobrze jest tagować ostatni stabilny commit (robi to project master). Na remote wysyłam każdy branch, jak coś wymaga brancha wykonanie zajmuje od kilku dni+, wówczas na remote jest extra kopia zapasowa (dodatkowo jest dostęp do repo poza firmą, o ile firma na to pozwala)

2
winerfresh napisał(a):

Mergowaniem powinien się zająć project master, który jeśli będzie trzeba będzie nawet ślęczał i ręcznie robił cherry-picki.

Powaznie? Mi sie wydaje ze jednak sensowniejsze jest zeby w mergowaniu bral udzial jeden z ludkow ktorzy brali udzial w tworezeniu brancha, przeciez taki master moze nie miec pojecia co i dlaczego (zakladam brutalna rzeczywistosc gdzie commenty zarowno w kodzie jak i w commitach sa kiepskie).
My nie uzywamy gita tylko mercuriala, i ogolnie mergowaniem zajmuje sie ten, kto dana galaz chce wmergowac. Dziala w porzadku. Nie ma jednej osoby ktora ma bardzo szczegolowa wiedze na temat calego systemu, wiec moze po prostu nie wiedziec nawet jak cos dziala i jak zmergowac. Wydaje mi sie ze tylko w najmniejszych projekcikach taka osoba istnieje, i moze sama wszystko mergowac. Nawet Linus nie wszystko w kernelu ogarnia i ma generalow od takich zadan. On merguje tylko wlasnie od tych generalow, i prowadzi czesto dialog co i dlaczego.

0

Ja osobiscie wole taki sposob: jeden branch master / default z ktrego sie buduje (plus jakies stable czy nie, jesli ktos chce), i jeden branch na feature; taki feature ma od 1 do N comittow; od czasu do czasu (zalezy od projektu) merge z mastera / default do feature (jesli jest wystarczajaco dlugi); gdy sie feature skonczy to merge do default bez fast forwarda - to spowoduje kilka rzeczy - bardzo ladne drzewko ktore mowi dokladnie jak przebiagala praca na projektem, gdzie byly feature a gdzie nie, i gdzie byl merge. Jesli robimy fast-forward (chyba domyslne ustawienie) i nastepnie kasujemy nazwe brancha to od tej chwili nie widac ze to byl osobny feature branch bo wychodzi z tego prosta linia. Faktem jest ze ja glownie uzywam mercuriala i tak takie dzialanie jest domyslne, ale wkrotce zmieniam prace i tam bedzie git wiec pewnie bede mial okazje wyprobowac inne workflowy i zobaczyc czy mi podchodza. Squashowanie brancha w jeden wielki commit uwazam osobiscie za bezsens, ale to kwestia gustu. Pytanie jest jedno: albo historia jest ladnym, niemalze prostym (ekstremum) DAG albo jest miejscem gdzie zachowane sa informacje na temat wszystkich dzialan zespolu. Ja wole to drugie.
Tutaj jeszcze fajny artykul ktory pewnie wiekszosc tutaj zna i ktory jest rozwinieciem tego opisanego przeze mnie powyzej (dochodza releasy i bugfixy, nie wszyscy jednak to potrzebuja): http://nvie.com/posts/a-successful-git-branching-model/.

1 użytkowników online, w tym zalogowanych: 0, gości: 1