[zapomnialemjakiebylohaslo]

#programowanie #githuboners
Jak macie 3 funkcjonalności, która każda kolejna potrzebuje wcześniejszej by działać i chcę mieć 1 PR - 1 ficzer, to czy ficzer trzeci może zawierać wcześniejsze PR czy tylko zmiany które sticte jego dotyczą?-i wtedy należy tworzyć powiązania w PM by zachować kolejność?

[garbaty33]

@zapomnialemjakiebylohaslo: no zależy od tego jak macie ustalone w zespole, ale raczej PR powinien zawierać wszystko, tak żeby po mergu tylko jednego z nich można było to przetestować i będzie działać.

[zapomnialemjakiebylohaslo]

@garbaty33: aha ok, wlasnie zastanawialem sie jaka jest 'ta słuszna droga' żeby zachować logikę i porządek :P

[zapomnialemjakiebylohaslo]

@garbaty33: a co jeśli jest 30 PR? to wtedy sprawdza sie od najstarszego? jest jakas dokumentacja 'dobrych praktyk' dla zarzadzania duzym projektem na gicie? hmmmm

[y.....l]

@zapomnialemjakiebylohaslo: Jeden PR zawsze dotyczy jednego ficzera, nie musi to być od razu cała implementacja oczywiście, ale mieszkanie dwóch różnych rzeczy w jednym PR według mnie jest niedopuszczalne. Widziałem takie potworki w stylu "add A, modify B and refactor C".

[Saly]

@zapomnialemjakiebylohaslo: generalnie starasz się robić tak, żeby tworzyć PR po kolei, czyli każdy kolejny wywodzi się od mastera. Oczywiście nie zawsze tak się da np. jak ty piszesz szybko a review idzie powoli. Wtedy w zasadzie nie ma dobrego rozwiązania, ja robię tak, że piszę w komentarzu, że ten PR jest zależny od tego, ewentualnie czekam na merge tego pierwszego i wtedy nie ma tego problemu

[Saly]

: a co jeśli jest 30 PR?

@zapomnialemjakiebylohaslo: teraz w modzie jest trunk based development, który polega na tym, że branche żyją bardzo krótko: robisz jakąś zmianę (małą, oczywiście w granicach rozsądku) robisz PR, mergujesz do mastera i tak w kółko.Jak masz 30 PRów w review to problemem jest to, że wrzucasz kod, który jest trudny: wtedy pomaga podzielnie PRów na mniejsze, bo im mniejszy PR tym łatwiej zrozumieć co zmienia.