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

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.

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

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.

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.

• 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.

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.

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.

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.

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”.