Jakie modele rozgałęziające Git działają dla Ciebie?

Myślę, i mogę się mylić, że jedną z rzeczy, które są najbardziej niezrozumiane w git jest jego rozproszona natura. To sprawia, że bardzo różnie można powiedzieć subversion w sposób, w jaki można pracować, chociaż można naśladować zachowanie SVN, jeśli chcesz. Problemem jest prawie każdy przepływ pracy, który jest świetny, ale także wprowadzający w błąd.

Jeśli dobrze rozumiem rozwój jądra (na tym się skupię), każdy ma własne repozytorium git do tworzenia jądra. Tam jest jednym repozytorium, linux-2.6.git, pod opieką Torvaldsa, który działa jako repozytorium release. Ludzie klonują się stąd, jeśli chcą zacząć rozwijać funkcję przeciwko gałęzi "release".

Inne repozytoria rozwijają się. Chodzi o to, aby klonować z linuksa-2.6, rozgałęziać się tyle razy, ile chcesz, aż do momentu, w którym masz działającą" nową " funkcję. Następnie, gdy będzie to gotowe, możesz udostępnić go komuś, kto uważa się za zaufanego, który wyciągnie tę gałąź z twojego repozytorium do ich i połączyć go z głównym nurtem. W jądrze Linuksa dzieje się to na kilku poziomach (zaufanych), aż dotrze do linuksa-2.6.git w tym momencie staje się"jądrem".

Teraz tutaj robi się mylące. Nazwy gałęzi w ogóle nie muszą być spójne w repozytoriach. Więc mogę {[0] } i uzyskać gałąź z master origin w gałęzi w moim repozytorium o nazwie vanilla-code. Pod warunkiem, że wiem o co chodzi, to naprawdę nie ma znaczenia - jest rozprowadzany w tym sensie, że wszystkie repozytoria są rówieśnikami, a nie tylko współdzielonymi między kilkoma komputerami, takimi jak SVN.

Tak więc, mając to wszystko na uwadze:]}

1. myślę, że to od każdego programisty zależy, jak robią swoje rozgałęzienia. Wszystko czego potrzebujesz to centralne repozytorium do zarządzania wydaniami itp. Bagażnik może być head. Wydania mogą być tagami lub gałęziami, a poprawki są prawdopodobnie gałęziami same w sobie. W zasadzie, prawdopodobnie zrobiłbym wydania jako gałęzie, żebyś mógł dalej łatać oni.
2. połączyłbym, a nie rebase. Jeśli na przykład weźmiesz repozytorium, sklonujesz je, rozgałęzisz i wykonasz jakiś dev, następnie ściągnij ze swojego origin powinieneś w swoim repozytorium prawdopodobnie utworzyć inną gałąź i scalić najnowszą master do yourbranch, aby ktoś inny mógł ściągnąć twoje zmiany przy jak najmniejszym wysiłku. Z mojego doświadczenia wynika, że bardzo rzadko istnieje potrzeba prawdziwie rebase.
3. myślę, że jest to przypadek zrozumienia sposobu działania Gita i tego, co potrafi. To trochę trwa i dużo dobrej komunikacji - naprawdę zacząłem rozumieć, co się dzieje, kiedy zacząłem używać Gita z innymi programistami i nawet teraz, niektórych rzeczy nie jestem pewien.
4. konflikty scalające są przydatne. Wiem, wiem, chcesz, żeby wszystko działało, ale faktem jest, że kod zmienia się i musisz połączyć wyniki w coś, co działa. Konflikty scalające to w rzeczywistości tylko więcej programowania. Nigdy nie znalazłem łatwego wyjaśnienia, co z nimi zrobić, więc oto jest: zwróć uwagę na pliki, które mieć konflikty scalania, przejść i zmienić je na to, co powinno być, git add . a następnie git commit.
5. jakkolwiek to pasuje. Jak już powiedziałem, każdy użytkownik repozytorium git jest do zabawy i nazwy gałęzi nie muszą być takie same . Jeśli na przykład masz repozytorium pośredniczące, możesz wymusić schemat nazewnictwa, ale nie musisz tego robić dla każdego dewelopera, tylko w repo wydania.
6. to jest etap połączenia. Scala się do gałęzi release itp. tylko wtedy, gdy uznasz kod za sprawdzone / przechodzą testy jakości.

Mam nadzieję, że to pomoże. Zdaję sobie sprawę, że VonC właśnie zamieścił bardzo podobne Wyjaśnienie... Nie umiem pisać wystarczająco szybko!

Edytuj kilka dalszych przemyśleń na temat tego, jak używać git w komercyjnym środowisku, ponieważ wydaje się to istotne dla OP z komentarzy:

• repozytorium wersji, nazwiemy je product.git, jest dostępne dla wielu starszych programistów / osób technicznych odpowiedzialnych za opiekę nad samym produktem. Oni są analogiczne do roli opiekunów w OSS.
• Ci Programiści prawdopodobnie również częściowo prowadzą rozwój nowych wersji, więc mogą również samodzielnie kodować i utrzymywać repozytoria varios. Mogą zarządzać repozytoriami przejściowymi dla naprawdę nowych funkcji, a także mogą mieć własne repozytoria.
• Poniżej znajdują się Programiści odpowiedzialni za tworzenie poszczególnych bitów. Na przykład ktoś może być odpowiedzialny za działanie interfejsu użytkownika. W związku z tym zarządzają interfejsem użytkownika.git repozytorium.
• Poniżej znajdują się prawdziwi programiści, którzy rozwijają funkcje jako swoją codzienną pracę.

Więc co się dzieje? Cóż, każdy wyciąga na początku każdego dnia ze źródła "upstream" tj. repozytorium release (które prawdopodobnie będzie również zawierać najnowsze materiały z poprzednich dni rozwoju). Każdy to robi, bezpośrednio. To trafi na gałąź w ich repozytorium, prawdopodobnie o nazwie "master", a może jeśli jesteś mną o nazwie "latest". Na programista wykona wtedy pewną pracę. Ta praca może być czymś, czego nie są pewni, więc tworzą gałąź, wykonują pracę. Jeśli to nie zadziała, mogą usunąć gałąź i wrócić. Jeśli tak się stanie, będą musieli połączyć się z główną gałęzią, nad którą aktualnie pracują. Powiedzmy, że jest to programista UI pracujący nad latest-ui, więc robi to git checkout latest-ui, a następnie git merge abc-ui-mywhizzynewfeature. Następnie mówi jego techniczny ołowiu (UI lead) Hej, wykonałem takie zadanie, wyciągnąć ode mnie. Tak prowadzi UI git pull user-repo lastest-ui:lastest-ui-suchafeature-abc. UI lead następnie spojrzy na to na tej gałęzi i mówi, właściwie, to bardzo dobrze, połączę to w ui-latest. Może wtedy powiedzieć wszystkim pod nim, aby wyciągnęli z niego swoje gałęzie lub jakiekolwiek imię, które im nadali, a więc funkcja zostanie zbadana przez deweloperów. Jeśli zespół jest zadowolony, prowadzący interfejs użytkownika może poprosić prowadzącego testy, aby wyciągnął z niego i połączył zmiany. To propaguje się do wszystkich (poniżej zmiany), którzy testują go i przesyła raporty o błędach itp. Wreszcie, jeśli funkcja przejdzie testowanie itp, jeden z najlepszych potencjalnych klientów technicznych może połączyć go z bieżącą roboczą kopią programu, w którym to momencie wszystkie zmiany są następnie propagowane z powrotem w dół. I tak dalej.

Nie jest to "tradycyjny" sposób pracy i jest zaprojektowany tak, aby był "peer driven", a nie "hierarchiczny", jak SVN/CVs. Zasadniczo każdy ma dostęp do commitów, ale tylko lokalnie. To dostęp do repozytorium i to, które repozytorium wyznaczasz jako release repo, pozwala na użycie hierarchii.

Model, który wykorzystałem z dobrymi wynikami jest następujący:

"błogosławiony" repo każdy pcha i ciągnie do/Z, W zasadzie topologia klient-serwer.

Nie ma gałęzi master, więc żaden programista nie może wcisnąć żadnego kodu do"mainline".

Wszystkie zmiany dzieją się na gałęziach tematycznych. Mamy nazwy przestrzeni nazw, aby łatwo wykryć, kto jest za to odpowiedzialny: jn / newFeature lub jn/issue-1234

Istnieje również blisko 1-to-1 mapowanie między gałęziami i kanban / karty scrum na tablica.

Aby zwolnić gałąź jest pchany do Błogosławionego repo i kanban-karta jest przenoszona do ready do przeglądu.

Wtedy, jeśli branch zostanie zaakceptowany przez przegląd, jest kandydatem do wydania.

Wydanie ma miejsce, gdy zestaw zaakceptowanych gałęzi zostanie scalony i oznaczony numerem wersji.

Poprzez wciśnięcie nowego tagu do the blessed repo istnieje nowa możliwa baza nowych funkcji.

Aby uniknąć konfliktów scalania programiści są uprzejmi poproszono o aktualizację (scalenie) niepublikowanych gałęzi do tagu najnowszego wydania.

Osobiście staram się zachować tylko kod release-ready w gałęzi master.

Gdy pracuję nad nową funkcją lub poprawką błędów, robię to w gałęzi. Testuję również jednostki w oddziale. Jeśli wszystko działa OK, tylko wtedy mogę połączyć / rebase z powrotem do master.

Staram się również używać wspólnych konwencji nazewnictwa gałęzi, takich jak:

• bugfix / recursive_loop
• bugfix / sql_timeout
• feature / new_layout
• feature / enhanced_search