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.
version-control
git
svn
branching
linuxunil
źródło
źródło
Odpowiedzi:
Istnieje kilka problemów, gdy zatwierdzenia są bezpośrednio wypychane do master
źródło
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.
źródło
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.
źródło
źródło
Po pierwsze, chcę podkreślić, że w git każdy
pull
jest dosłownie operacją rozgałęziającą, a każdapush
jest połączeniem. Namaster
maszynie programisty jest całkowicie oddzielna gałąź odmaster
centralnego repozytorium, które udostępniasz, z równą pozycją z technicznego punktu widzenia. Od czasu do czasu zmieniam nazwę mojej lokalnej wersji naupstream
coś 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.
źródło
pull
utworzyłby nowy oddział, ani jakpush
byłaby operacja łączenia. Raczejpull
jest dosłowniefetch
następnie przezmerge
!master
za inny oddziałorigin master
. Technicznie są to różne gałęzie na dwóch różnych pilotach, każdy z własną historią.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łbympush
to, ponieważ potencjalnie tworzy nową gałąź w zdalnym. To, czego nie robi, to połączenie.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.
źródło
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.
źródło
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”.
źródło