Strategia rozgałęziania Git dla długo nieużywanego kodu

W naszym zespole, oprócz poszczególnych jednostek pracy (Historie), mamy dłuższe motywy pracy (Epopeje). Liczne historie stają się epickie.

Tradycyjnie mieliśmy gałęzie funkcji dla każdej Opowieści i połączyliśmy je prosto do opanowania, gdy przejdą kontrolę jakości. Chcielibyśmy jednak zacząć powstrzymywać się od wydania ukończonych historii w Eposie, dopóki Epicka nie zostanie uznana za „pełną funkcję”. Wydamy te funkcje do produkcji dopiero po zamknięciu całej Epiki. Co więcej, mamy serwer budowania na noc - chcielibyśmy, aby wszystkie zamknięte Historie (w tym te, które są częścią niekompletnych Eposów) były automatycznie wdrażane na tym serwerze na noc.

Czy są jakieś sugestie, jak zarządzać naszym repozytorium, aby to osiągnąć? Zastanawiałem się nad wprowadzeniem „epickich gałęzi”, w których scalilibyśmy zamknięte historie z pokrewną epicką gałęzią zamiast bezpośrednio w master, ale mam obawy:

• Martwię się o konflikty scalania, które mogą powstać, jeśli epickie gałęzie będą otwarte przez długi czas
• Kompilacje nocne wymagałyby połączenia wszystkich epickich gałęzi w gałąź „kompilacji nocnej”. Ponownie mogą pojawić się konflikty scalania i należy to zrobić automatycznie

Prosta sugestia: nie rób tego.

gałęzie git nie są przeznaczone do długotrwałych rozwidleń kodu, jak omówiono tutaj i https://blog.newrelic.com/2012/11/14/long-running-branches-consisted-harmful/ . Oddziały najlepiej traktować jako przejściowe rzeczy używane do organizowania zatwierdzeń przez indywidualnych programistów na poziomie codziennym. Więc jeśli mają nazwę, która odpowiada czemuś kierownikowi projektu (nie wspominając o użytkownikach końcowych) może troszczyć się o to, że robisz coś źle.

Zalecaną praktyką jest ciągła integracja z przełączaniem funkcji lub przełączaniem według gałęzi, aby zapewnić, że:

• cały kod jest zintegrowany przez cały czas (przynajmniej codziennie, najlepiej częściej)
• to, co zostanie wdrożone, jest pod wyraźną kontrolą.

Myślę, że jest to dość powszechny problem i sprowadza się do wyboru, które funkcje mają zostać uwzględnione w wydaniu po ich zakodowaniu, a nie wcześniej.

na przykład.

Mam funkcje A, B i C dla wersji 2 mojego produktu. B i C są powiązane, nie chcę wypuszczać B, chyba że C również jest skończone.

Mam trzech programistów pracujących nad funkcjami jednocześnie.

Mam datę wydania kamienia D

B jest zakończone i połączone, A jest zakończone i połączone. C jest opóźnione ... co mam zrobić ?!

Nie wierzę, że istnieje techniczne rozwiązanie tego problemu. Chcesz wypuścić niesprawdzoną wersję produktu z dołączoną tylko funkcją A. O ile nie scalisz i nie przetestujesz wszystkich możliwych kombinacji funkcji, zawsze będzie to możliwe.

Rozwiązanie jest bardziej ludzkie. Nie znasz daty premiery i musisz ją cofnąć.

To trudny problem, z którym boryka się wiele osób. Wolę używać konfiguracji Gitflow jako punktu wyjścia.

Rozwój -> Nowe prace nad
Master -> Gotowe rzeczy wymagające testowania Produkcja -> Rzeczy, które zostały opublikowane do produkcji.

Przy mniejszych (krótszych) funkcjach tworzę gałąź od programowania, pracuję tam, a następnie łączę gałąź z powrotem z programowaniem.

Przy głównych (długoterminowych) funkcjach tworzę gałąź z rozwoju, tworzę mniejsze gałęzie z tej gałęzi, a następnie łączę z powrotem do pierwszej gałęzi. Po zakończeniu głównej funkcji wraca ona do gałęzi programistycznej.

W regularnych odstępach czasu (w zależności od projektu) łączę programowanie z powrotem w master i rozpoczyna się cykl testowania. Jeśli jakieś poprawki pojawią się w trakcie testowania, zostaną wykonane w gałęzi master (gałąź sub, a następnie scalona). Podczas testów można kontynuować rozwój gałęzi master.

W dowolnym momencie master powinien zostać włączony do rozwoju, a rozwój powinien zostać połączony z dowolnym z jego długoterminowych oddziałów.

mistrz powinien zawsze (teoretycznie) być gotowy do produkcji. Rozwój powinien zawsze (teoretycznie) być gotowy do produkcji. Jedyny powód, dla którego istnieje różnica, to zapewnienie solidnego zestawu funkcji do testowania przez testerów.

Gdy jest gotowy, testowane zatwierdzenie w wzorcu jest łączone z produkcją, a wdrażanie w produkcji odbywa się z tej gałęzi. Poprawki, które należy wykonać w nagłych wypadkach, mogą następnie odbywać się w oddziale produkcyjnym bez konieczności łączenia się w trybie głównym (który może zawierać wiele niesprawdzonych zmian).

Moje normalne Drzewo wygląda

 LongTerm -> Development -> Master -> Production    
 LongTerm <- Development      |            |  
     |       Development -> Master         |  
 LongTerm <- Development -> Master         |  
             Development <- Master         |  
                            Master -> Production  

Zasadą ogólną jest, że żadna zmiana nie powinna zająć więcej niż kilka godzin. Jeśli tak, należy wprowadzić mniejsze zmiany. Jeśli jest to ogromna funkcja (jak ponowne pisanie interfejsu użytkownika), to dzieje się to w dłuższej perspektywie, aby normalny rozwój mógł być kontynuowany w tym samym czasie. Oddziały LongTerm są zwykle tylko oddziałami lokalnymi, podczas gdy Programowanie, Master i Produkcja to oddziały zdalne. Wszelkie odgałęzienia są również tylko lokalne. Utrzymuje to repozytorium w czystości dla innych, bez utraty przydatności git na długoterminowym zestawie funkcji.

Chciałbym jednak zauważyć, że istnienie gałęzi długoterminowej jest rzadkością. Zwykle cała moja praca jest w fazie rozwoju. Tylko wtedy, gdy mam funkcję (zestaw), która zajmie tak długo, że muszę być w stanie pracować także nad normalnymi programami, korzystam z gałęzi LongTerm. Jeśli to tylko zestaw zmian, które powinny być razem, po prostu nie łączę się z mistrzem, dopóki wszystko się nie skończy.