[mk321]

#programowanie #git #gitlab #github #pracait

Jak macie dużego taska do zrobienia, to jak to robicie?

Przykładowo task: "Dodawanie wpisów na mikroblogu".

Na pewno nie zrobicie jednego ogromnego commita, tylko podzielicie to na mniejsze części np.:
- "proste dodawanie wpisów",
- "dodanie możliwości formatowania wpisów",
- "załączanie zdjęć do wpisów (z pliku)",
- "załączanie zdjęć do wpisów z adresu URL".

Na #gerrit ( #java znają) było tak, że robiło się powiązane commity i po kolei robiło się code review (autor robił poprawki poszczególnych commitów przez amend) i wchodziły po kolei poszczególne commity.

Ale teraz robi się pull/merge requesty. Jak teraz do tego się podchodzi?

Wrzucić wszystko w jednego merge requesta?
To bardzo duża zmiana do zrobienia code review naraz i będzie długo trwało zanim wejdzie. A może ktoś by chciał już z części skorzystać. Są inne taki, które inne osoby mogłyby robić np.:
- "Powiadomienia po dodaniu komentarzy" (potrzebny przynajmniej commit: "proste dodawanie wpisów"),
- "Edytor zdjęć przy ich dodawaniu" (potrzebne 3 commity aż do "załączanie zdjęć do wpisów (z pliku)").
Poprzednie commity mogłyby wcześniej wejść, ale np. ten ostatni utknie w code review (bo będzie z nim dużo błędów) i cały merge request nie będzie zmergowany, więc przez ten cały czas nikt nie może wziąć kolejnego taska.

A może powinno się każdego takiego commita wrzucić w osobne merge requesty?
Tylko jak zrobię pierwszego commita i tylko z niego zrobię merge requesta, to jak mam dalej pracować? (Zanim wejdzie ten merge request, bo trwa code review.)
Kolejny merge request to musi być kolejny branch (muszę wyjść z tego mojego brancha, który jest jeszcze w code review). Jak powiązać tego pull requesta z poprzednim? Bo przecież jak założę nowego pull requesta z tego drugiego brancha, to będę miał tam dwa commity (bo poprzedni jeszcze nie wszedł). Jak zablokować, żeby ktoś przypadkiem nie zmergował tego przed tamtym?
I co z poprawkami do tego poprzedniego? Jak zrobię na tym pierwszym to jak zaktualizować na kolejne branche? Przy takim jednym tasku będę miał 4 branche, co mocno komplikuje.

[kapelusz]

@mk321: siemka. nie wiem czy widziałeś dosyć fajny wpis Fowlera o różnych modelach: https://martinfowler.com/articles/branching-patterns.html

Na gerricie działaliśmy jeszcze inaczej niż opisujesz - raczej nie dodawaliśmy nowych rzeczy do commita przez ammendy - tylko poprawki do review. Natomiast wszystkie te commity szły na feature branch, który dopiero trafiał na release brancha gdy był czas na wydanie. Co prawda powodowało to że zmiany z innych feature branchy trzeba było mergować, co było dosyć

[Arveit]

@mk321: troche późno, ale https://devstyle.pl/2018/10/26/5-sposobow-na-prace-z-gitem/

Commituję praktycznie każdą zmianę, od której oczekuję zmiany działania fragmentu kodu. Nie zawsze się da, czasem jest poczucie, że te commity są zbyt małe, ale zawsze przed pushowaniem można commity ze sobą złączyć. No i korzystam z git log jak z historii tego co akurat robię. Jak np. odchodzę od kompa i wracam, wklepuję git log -1 i mam ostatniego commita. Albo dodaję sobie alias na