W jaki sposób tworzysz strukturę przepływu pracy repozytorium Git?

Question

Oglądaliśmy i oglądaliśmy filmy o tym, jak duże rozproszone zespoły używają Git, ale co z tymi z nas, którzy nie są dystrybuowani i którzy pracują w biurze z resztą naszego zespołu? Jak powinniśmy strukturyzować nasze repozytorium (e) i nasz przepływ pracy?

Pomyśl o tradycyjnym biurze, które używa Subversion lub CVS jako pojedynczego punktu władzy. Z pewnością te zespoły mogły utrzymywać własne repozytorium Git i pchać/ciągnąć między sobą w razie potrzeby, co w wielu sytuacjach szybko przerodziłoby się w koszmar. Mogą też utrzymywać własne repozytorium i synchronizować je z jednym repozytorium, które jest znane jako "mistrz" dla zespołu. Lub może istnieć dowolna kombinacja przepływów pracy z możliwościami, które otwiera DVCS.

Jak działa Twój zespół? Co okazało się przydatnym przepływem pracy?

Answer 1

Podoba mi się sposób, w jaki Yahoo! Wygląda na to, że zespół interfejsu użytkownika (YUI) działa. Nie jestem na Yahoo, ani ja w tym zespole, ale ich dzienniki zatwierdzania git ujawniają wiele o ich procesie.

Zespół YUI utrzymuje centralne repozytorium, w którym wszyscy członkowie zespołu mają dostęp do commitowania. Okresowo po zatwierdzeniu do tego repozytorium (może to być po każdym naciśnięciu, ale nie sądzę), system kompilacji uruchamia, przebudowuje YUI i wypycha nowo oznaczony commit do github, gdzie społeczność może rozwidlić kod i pracować nad nim .

Jestem za centralnym repozytorium, które reprezentuje "oficjalny" status projektu. Oczywiście, jeśli chcę podzielić się kodem ze współpracownikiem, mogę zorganizować dla nich odebranie ode mnie oddziału i możemy współpracować w ten sposób.

Repozytorium "master" oferuje również inne zalety, takie jak łatwość ciągłej integracji, ponieważ wyzwalacze push/pull mogą być konfigurowane w repozytorium "master" w celu odpalenia testów jednostkowych i zbudowania systemu. Zapewnia to również, że każdy wie, gdzie jest najnowsza "znana dobra" wersja repozytorium, więc jeśli projekt musi zostać zbudowany, opublikowany lub przetestowany, może istnieć uzasadnione zapewnienie, że repozytorium "master" jest na to gotowe .

Git obsługuje prawie każdy przepływ pracy, ale nawet w małym zespole nie chcesz, aby istniało pytanie o to, gdzie znajduje się "oficjalne" repozytorium. Koszmar utrzymania, który mógłby doprowadzić, szczególnie gdy zbliżasz się do wydania, byłby nieprzyjemny.

Answer 2

przyjrzeć ładnym blogu http://nvie.com/git-model i komentuje

Answer 3

Spójrz na zespole workflow github używa:

http://scottchacon.com/2011/08/31/github-flow.html

Wymaga użyciu GitHub, ale również jest bardzo proste i czyste.