Git - Jakie problemy wynikają z bezpośredniej pracy nad masterem?

25

Widziałem wiele porad na temat modeli rozgałęziania git i najczęstszą opinią wydaje się, że wprowadzanie zmian bezpośrednio w gałęzi master jest złym pomysłem.

Jeden z naszych współpracowników jest całkiem zadowolony z wprowadzania zmian bezpośrednio w głównej gałęzi i pomimo kilku rozmów wydaje się, że raczej tego nie zmienią.

W tej chwili nie mogę przekonać współpracownika, który jest złą praktyką do pracy bezpośrednio nad mistrzem, ale chciałbym zrozumieć rzeczy, które będą kolidować z jego sposobem pracy, aby wiedzieć, kiedy muszę ponownie odwiedzić ten przypadek.

linuxunil
źródło
2
Zdefiniuj „działający bezpośrednio”. Mistrz istnieje, ponieważ jest przeznaczony do użycia. Jak myślisz, po co to jest, a po co nie?
candied_orange
3
Czy praca dla mistrza działa dla ciebie? Jeśli tak, dlaczego czujesz potrzebę zmiany w tej chwili? Jeśli to nie działa, jaki problem występuje? Zamiast prosić ludzi o wskazanie argumentów innych osób, możemy pomóc Ci rozwiązać Twoje problemy.
Thomas Owens
1
Wygląda na to, że rozwija pień, co wraz z ciągłą integracją jest dość normalne w zespole Agile. Jeśli chce pracować w ten sposób, będziesz musiał egzekwować WIP, aby upewnić się, że nigdy nie dzieje się zbyt wiele pracy nad jednym produktem naraz - a także użyć przełączania funkcji, aby zapewnić, że master może zostać wydany z wyłączonymi niekompletnymi funkcjami.
Pan Cochese,
... jak duży jest zespół?
ZJR,
@MrCochese Nie nazwałbym rozwoju tułowia w tym znaczeniu „normalnym”. Z pewnością żadne z wielu miejsc, w których korzystałem z Gita, nie działało w ten sposób i odradzałbym to. Gałęzie funkcji po prostu działają lepiej.
Marnen Laibow-Koser

Odpowiedzi:

57

Istnieje kilka problemów, gdy zatwierdzenia są bezpośrednio wypychane do master

  • Jeśli przekażesz stan pracy w toku do zdalnego, master może zostać uszkodzony
  • Jeśli inny programista zacznie pracę nad nową funkcją od mistrza, zacznie od stanu potencjalnie uszkodzonego. Spowalnia to rozwój
  • Różne funkcje / poprawki błędów nie są izolowane, więc złożoność wszystkich trwających zadań programistycznych jest połączona w jednym oddziale. Zwiększa to niezbędną komunikację między wszystkimi programistami
  • Nie można wykonywać żądań ściągania, które są bardzo dobrym mechanizmem do sprawdzania kodu
  • Nie można ogólnie zgniatać zatwierdzeń / zmieniać historii git, ponieważ inni programiści mogli już w międzyczasie wyciągnąć gałąź master
Gernot
źródło
11
Hej, patrz! Właściwie odpowiedziałeś na pytanie, w przeciwieństwie do praktycznie wszystkich innych. ++ Witamy w SE.SE!
RubberDuck,
Większość z nich to problemy pochodzące z pracy bezpośrednio na mistrza źle , a nie działa bezpośrednio na pana per se.
Ant P
1
@AntP, którym problemom można by zapobiec z twojego punktu widzenia?
Gernot,
10

Wyjaśnij mu, że nowe funkcje potrzebują własnej gałęzi programistycznej, którą można wdrożyć w środowisku testowym przed wprowadzeniem do produkcji.

W przeciwnym razie jesteś w stanie ciągłym niepełnych funkcji. Nie możesz wdrożyć w pełni niedokończonych funkcji do produkcji, więc jeśli pracujesz bezpośrednio w gałęzi głównej, wszyscy inni muszą poczekać, aż zakończysz swoją funkcję, zanim zmiany wprowadzone przez kogoś innego zostaną wprowadzone do produkcji, w tym poprawki błędów.

Korzystanie z niezależnych gałęzi dla funkcji oznacza, że ​​każdą nową funkcję można testować i wdrażać niezależnie od innych.

Robert Harvey
źródło
„Nie można wdrożyć w pełni niedokończonych funkcji do produkcji” - to wcale nie jest prawda - jest całkowicie możliwa praca bezpośrednio w głównej gałęzi, wysyłanie kodu przy każdym zatwierdzeniu, często wdrażanie „w połowie ukończonych funkcji” i nigdy nic nie psuje . Ciągłe dostarczanie polega właśnie na tym, aby wykonać dokładnie to: oddzielenie wdrażania od wydania. Co dzieje się również w celu rozwiązania wielu innych problemów organizacyjnych, które ludzie zwykle rozwiązują za pomocą częściowo zepsutych rozwiązań technicznych. Czasami wymaga to przełączania funkcji, ale zwykle można zbudować i wdrożyć 90% funkcji bez widocznych zmian zachowania.
Ant P
@AntP: proces, który opisujesz, nie jest tym, co nazwałbym „funkcjami w połowie ukończonymi”. Takie cechy są albo przetestowany, gotowy do produkcji i użytku, albo są one ukryte za pomocą przełącznika funkcji lub coś podobnego do czasu, gdy oni testowane, produkcja i gotowe do użytku. Nie dostarczasz funkcji, które nie działają.
Robert Harvey
Zapewniłeś, że należy opracować nowe funkcje w gałęziach innych niż master, ponieważ nie można wdrożyć częściowo ukończonych gałęzi: tak nie jest. Absolutnie możesz opracowywać nowe funkcje bezpośrednio na urządzeniu głównym i wysyłać dowolny kod związany z tymi funkcjami do produkcji, zanim ta funkcja będzie kompletna i nie będziesz wstrzymywać innych prac rozwojowych.
Ant P
1
@AntP: Jedną z cech gałęzi funkcji, których nie jest w stanie zapewnić twoja technika, jest pełne rozliczenie pracy wykonanej na określonej funkcji. W niektórych sklepach (w szczególności moich) ten rodzaj odpowiedzialności nie jest luksusem, ale raczej wymogiem.
Robert Harvey,
1
@AntP Jeśli dobrze cię rozumiem, uważam to za krok wstecz. Uwielbiam dobre narzędzia do śledzenia problemów i używam ich szeroko, ale chcę, aby VCS opowiedział mi historię rozwoju dowolnej funkcji lub linii kodu. Narzędzie do śledzenia problemów może opowiedzieć historię biznesowej zmiany, ale jeśli VCS nie może mi pomóc samodzielnie śledzić i kontrolować kodu , oznacza to, że nie spełnia swojej roli. Jest to jeden z powodów, dla których sprzeciwiam się rozwojowi opartemu na tułowiu: sprawia, że ​​VCS jest głupi, bez widocznej korzyści kompensacyjnej. (Również: kruche sprzężenie? Cechą jest zmiana kodu.)
Marnen Laibow-Koser
2

Master powinien być potencjalnie uwalnialny. Kropka. Nie powinno być w połowie ukończonych prac w trybie głównym (chyba że wyłączone z flagą funkcji)

Powiedziawszy to, widziałem, jak niektóre zespoły komplikują przepływ.

Nieużywanie PR podczas integracji z masterem jest błędem, ponieważ programiści nie będą mieli możliwości wyboru, kiedy nastąpi integracja.

Pojedyncza gałąź programistyczna przynosi bardzo niewielką wartość. Zwykle to tylko komplikuje. Wiele gałęzi funkcji ma dużą wartość.

Tworzenie gałęzi dla każdego środowiska (deweloper, test, prod) jest błędem. Jest to poza zasięgiem git i powinno być obsługiwane przez potok wydania. Dokładnie taką samą kompilację należy wdrożyć we wszystkich środowiskach, co jest niemożliwe, jeśli dla każdego środowiska istnieją gałęzie.

Jeśli cecha jest tak duża, że ​​nie można tego zrobić w ciągu jednego lub dwóch dni, cała praca nad gałęzią funkcji powinna być w osobnych gałęziach i zintegrowana z PR.

Esben Skov Pedersen
źródło
Zgadzam się z większością tego, co powiedziałeś, z wyjątkiem tego: „Ta sama kompilacja powinna zostać wdrożona we wszystkich środowiskach”. W rzeczywistości potok wydania powinien zasadniczo być w stanie wdrażać różne kompilacje w różnych środowiskach, a następnie promować je po przejściu testów. Jak sobie z tym poradzić, jeśli nie z różnymi gałęziami (lub przynajmniej różnymi tagami)?
Marnen Laibow-Koser
Może nie byłem do końca jasny. Po wdrożeniu kompilacji w środowisku. Te same artefakty powinny zostać wdrożone w następnym środowisku bez konieczności przebudowy.
Esben Skov Pedersen
Jeśli masz powtarzalne kompilacje, nie powinno mieć znaczenia, czy przebudujesz. Jeśli nie masz powtarzalnych wersji, masz większe problemy. :)
Marnen Laibow-Koser
... ale tak, myślę, że powinieneś oznaczyć swoje wdrożone commity, aby promować ten sam kod (niezależnie od tego, czy przebudujesz).
Marnen Laibow-Koser
Tak, ale większość serwerów CI może łączyć kompilacje z wydaniami od razu po wyjęciu z pudełka, co ułatwia śledzenie wdrożeń. Po prawidłowej konfiguracji nie jest tak naprawdę potrzebne do śledzenia wdrożeń w git. Git to scm. Nie narzędzie do wdrażania.
Esben Skov Pedersen
2
  • Master powinien odzwierciedlać dział produkcji, działającą wersję ostateczną.
  • Praca bezpośrednio w trybie głównym oznacza, że ​​jeśli tworzysz błędy, nie masz innej opcji „powrotu” niż cofanie / usuwanie / resetowanie zatwierdzeń, co nie jest czystym sposobem pracy i może spowodować utratę części nowego kodu, które były OK.
  • Oczywiście, na pierwszych etapach rozwoju być może możesz rozpocząć pracę bezpośrednio nad masterem, ale po tym, jak masz coś do dostarczenia, powinieneś użyć gałęzi programowania, testowania lub eksperymentowania, aby nie dotykać opublikowanej, kompletnej, działającej wersji.
Tulains Córdova
źródło
2

Po pierwsze, chcę podkreślić, że w git każdy pulljest dosłownie operacją rozgałęziającą, a każda pushjest połączeniem. Na mastermaszynie programisty jest całkowicie oddzielna gałąź od mastercentralnego repozytorium, które udostępniasz, z równą pozycją z technicznego punktu widzenia. Od czasu do czasu zmieniam nazwę mojej lokalnej wersji na upstreamcoś lub coś, jeśli bardziej odpowiada moim celom.

Zwracam na to uwagę, ponieważ wiele organizacji uważa, że ​​używają oddziałów bardziej efektywnie niż twój kolega, a tak naprawdę robią niewiele więcej niż tworzenie dodatkowej nazwy oddziału po drodze, która i tak nie zostanie zapisana w historii. Jeśli twój kolega zatwierdza funkcje w jednym zatwierdzeniu atomowym, wycofanie jest równie łatwe jak zatwierdzenie scalania gałęzi funkcji. Zdecydowana większość gałęzi fabularnych powinna być krótkotrwała i często łączona.

Biorąc to pod uwagę, główne wady jego stylu pracy są dwojakie. Po pierwsze, bardzo trudno jest współpracować przy niedokończonej funkcji. Utworzenie oddziału nie byłoby jednak trudne tylko w tych momentach, gdy potrzebna jest współpraca.

Po drugie, bardzo utrudnia przegląd przed scaleniem. W tym momencie tak naprawdę nie musisz go przekonywać. Możesz zastosować takie narzędzie, jak github, gerrit lub gitlab, i wymagać recenzji kodu żądania ściągania oraz pozytywnych testów automatycznych dla wszystkich połączeń. Jeśli nie robisz czegoś takiego, szczerze mówiąc, nie używasz git do pełnego potencjału i nic dziwnego, że twój kolega nie widzi tego potencjału.

Karl Bielefeldt
źródło
1
Również popychanie deweloperów jego / jej maszyny oddziałowej każdego dnia stanowi dobrą kopię zapasową.
Ian
Nie rozumiem twojego pierwszego zmysłu. Nie widzę, jak a pullutworzyłby nowy oddział, ani jak pushbyłaby operacja łączenia. Raczej pulljest dosłowniefetch następnie przez merge!
mkrieger1
@ mkrieger1 Z łatwością widzę, jak można uznać lokalny masterza inny oddział origin master. Technicznie są to różne gałęzie na dwóch różnych pilotach, każdy z własną historią.
RubberDuck,
@RubberDuck Tak, dokładnie. Z pull: Przed: dwie gałęzie potencjalnie wskazujące na różne zatwierdzenia - Po: dwie gałęzie wskazujące na równoważne zatwierdzenia - Nie utworzono żadnych gałęzi, dlatego nie nazwałbym tego „operacją rozgałęziania”. Jeśli którekolwiek z dwóch poleceń, nazwałbym pushto, ponieważ potencjalnie tworzy nową gałąź w zdalnym. To, czego nie robi, to połączenie.
mkrieger1
@ mkrieger1 należy również wziąć pod uwagę kierunek scalania.
RubberDuck,
2

Inne odpowiedzi wspominały już o różnych zaletach (izolowane funkcje, zawsze wysyłany kod na kapitale itp.) Do bezpośredniej pracy NIE na kapitale.

Wydaje mi się, że masz inny problem. Oczywiście nie masz procesu programistycznego, który jest uzgodniony lub używany przez wszystkich programistów (lub dany programista całkowicie ignoruje ten proces).

Czy masz gałęzie funkcji, które są połączone w trybie głównym, czy masz także różne gałęzie wydań, czy używasz zupełnie innego procesu?

„Nie używaj gałęzi głównej” nie jest wystarczające.

Szymon, Szymek
źródło
2

Jeden z naszych współpracowników jest całkiem zadowolony z wprowadzania zmian bezpośrednio w głównej gałęzi i pomimo kilku rozmów wydaje się, że raczej tego nie zmienią.

To prowadzi mnie do przekonania, że ​​jest więcej problemów. Praca nad masterem lub nie jest głównie częścią większej filozofii dotyczącej tego, jak, co i kiedy wypuszczasz produkty.

Więc w połączeniu z „nigdy nie powinieneś pracować na masterie”, czy masz testy funkcji, czy testujesz pracę innych, czy przeglądasz kod innych. Testy akceptacyjne i integracyjne.

Jeśli nie masz żadnego z powyższych i po prostu robisz to, aby „zrobić git”, równie dobrze możesz pracować nad masterem.

Pieter B.
źródło
1

Nie ma „złej praktyki” wokół pracy bezpośrednio w oddziale. Ale musisz zdecydować, co najlepiej wspiera Twój proces:

Pytanie 1: Czy twój mistrz powinien reprezentować aktualny stan twojego oprogramowania? Następnie powinieneś wprowadzić globalną gałąź programistyczną i scalić program pod koniec rozwoju wersji.

Pytanie 2: Czy chcesz mieć proces przeglądu kodu? Następnie powinieneś mieć „gałęzie funkcji”, które zostaną scalone w master (lub rozwijaj, jeśli je posiadasz) poprzez żądania ściągania.

Pytanie 3: Czy trzeba udostępniać stan kodu pośredniego innym programistom, których nie należy jeszcze publikować w wersji produkcyjnej (lub testowej)? Tak jest w przypadku, gdy więcej niż jeden programista rozwija funkcję. Następnie powinieneś wprowadzić „gałęzie funkcji”.

oopexpert
źródło
Znaczniki są bardzo realnym sposobem reprezentowania stanu bazy kodu w momencie wydania. Git sprawia, że ​​bardzo łatwo jest sprawdzić konkretny tag. Sprawia, że ​​gałąź deweloperów jest czymś spornym.
RubberDuck,