Obecnie pracuję nad projektem z zespołem korzystającym z przepływu pracy git. Jest to dość proste, master powinien być w stanie do wdrożenia, a do tworzenia funkcji i poprawek służą gałęzie. Ilekroć mamy ukończoną i przetestowaną funkcję lub poprawkę błędu, przenosimy ją do opanowania tak szybko, jak to możliwe. Chodzi o to, aby gałęzie były jak najmniejsze, aby ułatwić ich scalenie z powrotem w master. Mamy zasadę, że każdy kod przekazywany do gałęzi master powinien być w stanie do wdrożenia i przejść testy.
Mamy sytuację, w której jeden z programistów wykonał wiele pracy (kilka miesięcy) w jednym oddziale i gałąź ta nie została jeszcze z powrotem połączona z głównym. Jest teraz kilka osobnych funkcji i kilka zatwierdzeń w tej gałęzi, w zasadzie ta gałąź naprawdę powinna była zostać scalona już kilka razy, ale jak dotąd nie było. Większość kodu jest w dobrym stanie z testami jednostkowymi, które można połączyć z powrotem w master, ale najnowsze zmiany z pewnością nie powinny być, ponieważ nie zostały zakończone i nie zostały przetestowane.
Jaki jest najlepszy sposób radzenia sobie z sytuacją, w której jedna gałąź jest naprawdę daleko od innych? W jaki sposób możemy uniknąć, aby oddziały otrzymywały w przyszłości bardzo dużą liczbę zatwierdzeń od mistrza?
Odpowiedzi:
Pozwól programistom, którzy pracowali przez kilka miesięcy bez łączenia, naprawić to. Może uda im się połączyć jeden duży fragment kodu, a może kilka małych kawałków, aby scalić jeden po drugim. W każdym razie powinni wykonywać pracę nóg, aby rozwiązać problem, ponieważ spowodowali go.
Ogólnie nie martw się o to: to problem drugiego dewelopera. Jeśli dwie gałęzie są naprawdę zbyt daleko od siebie, aby się połączyć, to tak naprawdę nie są już częścią tego samego projektu i masz rozwidlenie defacto. Jeśli jest to projekt typu open source, może to nawet nie stanowić problemu.
Jeśli ten programista jest naprawdę genialny, a jego kod jest lepszy / mądrzejszy / ważniejszy niż reszta zespołu łącznie, warto uczynić go swoim problemem zamiast ich. W przeciwnym razie tak nie jest.
Aby odpowiedzieć na dosłowne pytanie: najlepszym sposobem na poradzenie sobie z tego rodzaju sytuacją jest uniknięcie takiej sytuacji.
Upewnij się, że wszyscy zauważają, że programista, który pracował przez wiele miesięcy bez łączenia, musi naprawić spowodowany problem. Upewnij się, że wszyscy wiedzą, że łatwiej jest zobowiązać się do opanowania często niż rzadko, ponieważ mniej zmian oznacza mniej okazji do konfliktów.
Upewnij się, że ludzie wiedzą, że mogą pobierać od mistrza, aby być na bieżąco z zmianami innych ludzi.
„Jeśli łączymy się każdego dnia, nagle nie dochodzimy do punktu, w którym mamy ogromne konflikty, które trudno rozwiązać”. --Linus Torvalds
Ten cytat pochodzi z rozmowy, którą wygłosił w Google, oto transkrypcja , a oto wideo .
źródło
Jeśli masz zatwierdzenie, które o tym wiesz i wszystkie poprzednie zatwierdzenia są dobrze przetestowane i powinny zostać scalone, po prostu odejdź od tego ostatniego dobrego zatwierdzenia i połącz nową gałąź z master.
Jeśli masz jakieś zatwierdzenia, które chciałbyś scalić, ale są one przeplatane z innymi zatwierdzeniami, które nie są gotowe do produkcji, to widzę 2 możliwości:
Jeśli chodzi o metody zapobiegania, spróbuj zdefiniować kilka zabawnych zasad zespołu, takich jak „Ten, który nie połączy się z mistrzem w ciągu tygodnia, zamówi pizzę na miesiąc”.
źródło
Najpierw sprawdź, czy naprawdę istnieją osobne zatwierdzenia, które można scalić lub wybrać, jak sugeruje @Maciej Chalpuk. Jeśli tak jest, sytuacja naprawdę nie jest taka zła i nie martwiłbym się tym zbytnio w przyszłości.
Jeśli jednak prawdziwa sytuacja polega na tym, że wiele funkcji zostało opracowanych jednocześnie w jednym oddziale, w ramach tych samych zatwierdzeń, wówczas znacznie trudniej sobie z tym poradzić. Na szczęście metoda zapobiegania jest wbudowana: wymaga od programisty oddzielenia zmian dla każdej funkcji w osobnych gałęziach i pobrania żądań przed ich scaleniem. Zarówno dostaniesz połączenia atomowe, jak i odwiedzisz tego programistę przed zrobieniem tego w przyszłość.
Rzeczywisty proces wydzielania funkcji jest całkowicie ręczny. Twórz nowe gałęzie poza wzorcem i kopiuj wszelkie zmiany z wielkiej gałęzi, które są z nią powiązane. Skompiluj, przetestuj funkcję, wypchnij i wydaj polecenie ściągnięcia. Im mniej splecione są zmiany kodu, tym łatwiej będzie to zrobić. Jeśli włamał się do jednej metody dla nich wszystkich, dobrze się baw. Nie zrobi tego ponownie.
źródło
Oto proste rozwiązanie.
Śledź funkcje zaimplementowane przez tę osobę i przejdź do każdego zatwierdzenia w tej gałęzi, która została zaktualizowana według funkcji. Weź to zatwierdzenie i połącz je z repozytorium głównym.
Pozwól mi to rozbić w formie przykładu.
Ta metoda może początkowo wydawać się sprzeczna z intuicją, ale jeśli scalisz każdą oddzielną nową funkcję samodzielnie z urządzeniem głównym, łatwo będzie przełączać się między gałęzią master „ według dodanej funkcji ”
Myślę, że moje powyższe rozwiązanie wskazuje, jaką metodę powinieneś zastosować w przyszłości. Wybierz metodę według funkcji lub zadania dla każdej gałęzi.
Sugerowałbym zastosowanie podejścia:
pre-master i master
master: końcowy / poziom produkcji. Nie jest często modyfikowany. Uważany jest za zawsze stabilny
pre-master: obszar, w którym nowa funkcja jest dodawana do istniejącego kodu. Został dokładnie przetestowany pod kątem pracy z istniejącą bazą kodu i jest miejscem, w którym inne gałęzie mogą rozwidlić się w celu wdrożenia nowej funkcji.
Powinieneś także wypróbować funkcje łączenia i celowania w wersje.
Kierowanie na wersję: Podaj dowolny numer, który będzie zastępczy dla gałęzi master. „W wersji 1.0.0 będziemy chcieli uzyskać funkcje X, Y, Z. Wersja 1.0.0 będzie również mieć wszystkie te funkcje dostępne: ...”
Utrzymanie wersji przeciwko wzorcowi może być również sposobem na utrzymanie „wzorcowego” stabilnego i gotowego do produkcji przez cały czas.
źródło
Naprawienie problemu dużego żądania ściągnięcia jest jedną rzeczą i jest na to kilka dobrych odpowiedzi. Ale w przypadku oddziałów, które stają się przestarzałe, możesz zrewidować swoje procesy radzenia sobie z pracą zespołową.
Jeśli pracujesz w ramach Agile lub SCRUM, zespół powinien naprawdę zapytać, dlaczego funkcja nie została ukończona i scalona w ramach iteracji / sprintu. Jeśli był „zbyt duży”, aby zmieścić się w iteracji, powinien był zostać podzielony na mniejsze części.
Rodzi to również kwestię własności kodu - czy w twoim zespole indywidualni programiści są właścicielami własnej pracy osobno, czy też cały zespół współpracuje ze sobą, aby zapewnić wykonanie zadań?
Oczywiście powyższe zakłada, że Twój zespół jest w jakiejś strukturze firmy. Jeśli jest to projekt typu open source z udziałem ochotników, to inna historia. Zasadniczo takie projekty mają luźniejszą kontrolę nad przepływami pracy, ale ciężar generowania akceptowalnych żądań ściągania spada częściej na poszczególnych autorów.
Na wiele sposobów staje się to pytaniem procesowym. Być może twój potrzebny proces obejmuje okresowe sprawdzanie (co tydzień? Co miesiąc?) Pod kątem długo działających, nie połączonych oddziałów. Niektóre narzędzia ułatwiają sprawdzenie wizualne; np. na github odwiedź link „oddziały”, który pokazuje, jak daleko znajduje się każda gałąź.
źródło