Czy są jakieś wady tego modelu rozgałęziania Git?

10

Pytam o ten model rozgałęzienia git lub przepływ pracy. Naprawdę to lubię. Wydaje mi się to bardzo intuicyjne i produktywne, ale pytam o to, czy są jakieś wady lub negatywy tego podejścia, które nie są jeszcze dla mnie jasne (pochodzące z innego świata, w którym rządziła ClearCase).

(Nie musisz odpowiadać na każde pytanie, cokolwiek możesz, jest pomocne)

  1. Czy używasz tego lub podobnego przepływu pracy rozgałęziania git?

  2. Czy uważasz to za produktywne podejście?

  3. Czy widzisz jakieś wady tego podejścia? Jakieś potencjalne miny?

  4. Jeśli masz lepsze podejście, czy mógłbyś udostępnić lub podać link do artykułu lub dyskusji na ten temat?

git workflows Todd Hopkinson
źródło

Odpowiedzi:

6

W przeważającej części jest to zwykły przepływ pracy stosowany w dowolnym VCS, z którego korzystaliśmy do tej pory. W przypadku niektórych (CVS, SVN) jest to trudniejsze, w przypadku GIT jest to banalne. To powiedziawszy, mam dwie uwagi:

Po pierwsze, istnieją dwie szkoły myślenia dotyczące gałęzi fabularnych:

  1. Scal je
  2. Odzyskaj je

(1) wydaje się sugerować artykuł. Problem z zatwierdzaniem scalania to tak zwane Połączenia Zła . W szczególności te, które łączą ścieżki rozwoju, w których funkcja zmieniła semantykę w jednej z gałęzi, ale automatyczne scalanie nie usuwa wszystkich wystąpień w kodzie pochodzącym z drugiej gałęzi. Regiony wprowadzone w ten sposób są niezwykle trudne do debugowania. Jako użytkownik GIT zazwyczaj możesz być bardziej zrelaksowany w kwestii regresji, ponieważ git bisectmusisz automatycznie znaleźć ich przyczyny. Jednak w opisanej sytuacji git bisectwskaże zatwierdzenie scalania, co wcale nie pomaga.

(2) pozwala uniknąć tego problemu, starając się zachować jak najbardziej liniową historię. Przeciwnicy rebase twierdzą, że unieważnia wszelkie testy, które mogłeś wykonać przed rebase.

Osobiście jestem mocno w obozie (2), ponieważ bardziej cenię ważność git bisectwyników niż potencjalną utratę zasięgu testu, co można łatwo zrekompensować za pomocą odpowiedniego systemu CI.

Po drugie, zdecydowałem, że przepychanie między programistami rzadko jest dobrym pomysłem. Istnieją problemy z bezpieczeństwem związane z umożliwieniem wszystkim ssh w twoim pudełku, aby pobrać lub uruchomieniem git-deamon lokalnie, a co ważniejsze, w zespołach niezbyt małych, nadzór może zostać utracony dość szybko.

To powiedziawszy, jestem zwolennikiem repozytorium pomostowego (czasami nazywanego także scratch ), które pozwala podelementom dzielić się swoją pracą w toku za pośrednictwem centralnego serwera, który jednak różni się od głównego (często zewnętrznego - skierowane, jeśli nie publiczne). Zazwyczaj każdy podzespół utrzymywałby dla siebie jedną gałąź tematyczną, a system CI dokonywałby okresowych połączeń ośmiornicy wszystkich gałęzi tematycznych w jedną dużą gałąź integracyjną, narzekając na konflikty i błędy kompilacji.

Społeczność
źródło
+1, nigdy nie słyszałem o repozytorium pomostowym nazywanym od zera, ale wyobrażam sobie, że pochodzi ono z „zaczynając od zera” :-)
Spoike 30.04.11
@ReinHenrichs: czy możesz zachować spokój i spierać się o to, dlaczego nie zgadzasz się z rebasingiem
CharlesB
2
Przepraszam. Zgłoszony problem git bisect nie istnieje. Dzielenie na dwie sekcje może być podzielone na zatwierdzenia scalania. Liniowa historia staje się trudna do utrzymania wraz ze wzrostem liczby programistów (lub gałęzi tematycznych). Co więcej, nie rozgałęziając się i nie scalając, tracisz bardzo potężne narzędzie przepływu pracy i jedną z głównych korzyści z używania git w pierwszej kolejności. Nie musisz „przepychać się między programistami”, możesz skonfigurować zdalne, publiczne (przynajmniej w ramach zespołu programistów) repozytorium dla każdego programisty. Łatwo to zrobić. To, co zasadniczo opisujesz, to używanie git jak svn.
Rein Henrichs
„zle łączenie się” jest starannie zapobiegane przez przeprowadzanie testów . Same zatwierdzenia scalania dostarczają użytecznych metadanych. Nie jestem pewien, jakie doświadczenie OP ma w utrzymywaniu repozytorium git z dużą liczbą tematycznych gałęzi. Wypróbowaliśmy strategię „bazowania i spłaszczania” w projekcie open source z setkami tematycznych gałęzi i rozpadła się pod złożonością. Przeszliśmy na strategię łączenia i wyeliminowaliśmy całą złożoność, dodając użyteczność bez żadnych domniemanych wad. git bisectpodano również jako powód do utrzymania płaskiej strategii.
Rein Henrichs
1
@ReinHenrichs „Zło łączy się”, które opisywał mmutz, nie ma nic wspólnego z git bisectsamym sobą. Dzieje się tak, gdy funkcja A zmienia funkcję, z której korzysta również funkcja B. Wszystkie testy przejdą zarówno A, jak i B przed scaleniem, ale po scaleniu testy mogą się przerwać z powodu niezgodnych zmian między A i B - ale git bisectnie mogą częściowo zastosować jednej gałęzi do drugiej, więc jedyną wskazówką jest to, że scalanie zatwierdza jest kiedy błąd został wprowadzony.
Izkata,
2

Obecnie robię masowe i długotrwałe refaktoryzacje (przekształcanie aplikacji z jednego na inny zestaw GUI) i wykonuję udany przepływ pracy zorientowany na bazę, ponieważ inni członkowie zespołu nadal pracują nad nowymi funkcjami:

Przeważnie są dwie główne gałęzie, mastergdzie rozwijane są nowe funkcje oraz toolkit-conversiongałąź. Najważniejsza zasada jest prosta: w toolkit-conversiongałęzi wykonuj tylko te czynności, które są istotne dla konwersji. Ilekroć jest coś, co można zrobić w master(starym zestawie narzędzi GUI), robię to tam i bazuję swoje toolkit-conversionzmiany na nowej mastergłowie. Kolejną zasadą jest utrzymywanie toolkit-conversiongałęzi dość krótkiej. Dlatego często używam resetowania, wybierania i zmiany-zatwierdzania i zmiany bazy, aby przykleić mniejsze zobowiązania do większych (które na końcu mają taki sam cel). Działa to również dobrze, gdy próbowałem czegoś, co nie zadziałało dobrze, aby „cofnąć” zmianę lub po ponownej obróbce kodu tymczasowym kodem pomocniczym.

Zdecydowałem przed scalanie zmian z masterdo toolkit-conversionoddziału, ponieważ miałoby to znacznie trudniejsze do rebase wcześniejsze zobowiązuje się do utrzymania w czystości i łatwe do przeglądu oddziału. Fuzje mogą również powodować konflikty, których rozwiązania nie są tak jasne, jak w przypadku prowadzenia czystej historii.

Oczywiście ten przepływ pracy ma również wady. Najważniejsze jest to, że działa dobrze tylko dla jednej osoby. Ilekroć zmuszam toolkit-conversiongałąź do przesunięcia na siłę po ponownym osadzeniu jej na głowie master, ciągnięcie jej do innego repozytorium staje się trudne (automatyczne przejście do gałęzi śledzącej często kończy się konfliktem).

Na koniec mój toolkit-conversionoddział pozostaje krótki, czysty i łatwy do przejrzenia. Nie mogłem sobie wyobrazić, że robiłem tak podobną moc z np. SVN.


źródło
2

W firmie, w której obecnie pracuję, od jakiegoś czasu stosujemy odmianę tego samego modelu rozgałęziającego. Używamy również Scruma, dlatego wykonujemy przepływ pracy według gałęzi.

Jedynym problemem, jaki do tej pory mieliśmy, jest to, że zespół jest wystarczająco duży i można rozpocząć więcej niż jedną historię, a te historie są od siebie zależne, łączenie zmian między oddziałami i powrót do mistrza staje się rodzajem bałaganu.

Poza tym okazało się to godne zaufania :).

Edgar Gonzalez
źródło
1

Obecnie jestem zajęty dostosowywaniem tego przepływu pracy. Myślę, że jest to całkiem niezły przepływ pracy, ponieważ wykorzystuje model rozgałęzienia, w którym przoduje git.

Jedynym niewielkim minusem jest to, że wymaga dyscypliny w utrzymywaniu tego przepływu pracy i nie próbuje robić skrótów.

Twórcy kohany również korzystają z tego przepływu pracy i wydaje się, że bardzo go lubią.

Ikke
źródło
1

Czy używasz tego lub podobnego przepływu pracy rozgałęziania git?

W pracy używamy podobnego przepływu pracy, ale nieco mniej skomplikowanego. Jest jednak bardzo zainspirowany tym procesem, ponieważ czytałem ten artykuł wiele razy. Mam nawet plik pdf modelu rozgałęzionego wydrukowany w kolorze obok mojego biurka :)

Czy uważasz to za produktywne podejście?

Produktywny. Jak definiujesz produktywność? Cóż, moim zdaniem najważniejsze jest, aby mieć wysoką jakość, przynajmniej starać się przez cały czas osiągać lepszą jakość. Ciągłe doskonalenie procesu itp. Jeśli możesz wyprodukować kod jakości, skorzysta na nim wydajność. Tak więc pytanie brzmi: czy poprawia to jakość oprogramowania? I moja odpowiedź na to pytanie jest zdecydowanie tak.

Najbardziej podoba mi się ten model rozgałęziania, ponieważ wprowadza rozgałęzienia w różnych warstwach jakości. Im bardziej na prawo na zdjęciu, tym wyższa stabilność i wyższa jakość. Gałąź główna jest święta i wszystkie zatwierdzenia na niej powinny być traktowane jako stabilne wersje oprogramowania. Im bardziej w lewo, tym bardziej eksperymentalny i niższa stabilność.

Gdy tylko przetestujesz nowe funkcje i poprawki błędów, możesz stopniowo przenosić je od lewej do prawej, a tym samym poruszać się w kodzie o wysokiej jakości dokładnie wtedy, gdy wiesz, że kod spełnia wymagania jakościowe, których wymagasz od kodu. Cóż, przynajmniej w teorii, ponieważ nie można przetestować wszystkiego do 100% i mieć pewność, że kod nie zawiera żadnych błędów, ponieważ zawsze będzie zawierał błędy. Ale pozwala zachować dużą pewność siebie.

Nic nie jest do bycia bardziej programistą niż praca w systemie, w którym nikt nie ma zaufania do kodu, ponieważ wiedzą, że jest do bani i że jest w nim mnóstwo błędów.

Czy widzisz jakieś wady tego podejścia? Jakieś potencjalne miny?

Ważne jest przemyślenie modelu rozgałęzienia, aby dobrze pasował do potrzeb Twojej organizacji. Tylko dlatego, że ten model działa dobrze dla niektórych osób, niekoniecznie oznacza, że ​​jest optymalny lub pożądany dla innego.

Zawsze występują kompromisy, a nawet w tym przypadku. Jednym z kompromisów jest liczba oddziałów w porównaniu ze złożonością. Wprowadzając wiele różnych typów gałęzi, zwiększasz złożoność przepływu pracy. Na przykład błędem może być zawsze zmuszanie ludzi do utworzenia nowej gałęzi funkcji, gdy próbują naprawić prosty błąd, zmieniając kilka wierszy kodu.

Wszyscy wiemy, że błędy są mniej lub bardziej skomplikowane do rozwiązania. Tak więc, gdy wykryty zostanie trywialny błąd, możesz zmniejszyć złożoność i administrację, aby pozbyć się dodatkowych kosztów ogólnych i po prostu pozwolić ludziom bezpośrednio zaangażować się np. W master lub gałąź rozwoju. Ale ponieważ natura twoich poprawek staje się bardziej skomplikowana, warto nałożyć dodatkowe koszty na tworzenie dla nich nowych gałęzi. Zwłaszcza jeśli nie masz pewności co do jego wielkości i długości lub chcesz poprawić współpracę między tobą a innymi programistami.

Jeśli masz lepsze podejście, czy mógłbyś udostępnić lub podać link do artykułu lub dyskusji na ten temat?

Jest to bez wątpienia dobre podejście i może pasować do większości przypadków, ponieważ większość z nas ma podobne procesy rozwoju, ale może nie być odpowiednie dla wszystkich. Usilnie nalegam, abyś przemyślał sposób postępowania z kodem w tej chwili i spróbował stworzyć model rozgałęzienia pasujący do tego, który już masz.

Najważniejsze jest, aby zacząć od git, a reszta nastąpi naturalnie. Zacznij prosto i stopniowo ulepszaj! Bądź kreatywny!

Twoje zdrowie


źródło