[olekturbo]

#programowanie jak to wyglada na #git gdy wysyłam pull request i przy code review wyjdzie ze coś jest nie tak i dostanę kilka komentarzy to wtedy poprawiam rzeczy commituje i wysyłam jeszcze raz PR?

[pkh]

Nie trzeba wysyłać drugi raz PR. Przeważnie wystarczy zrobić push z zmianami na brancha z którego zrobiłeś PR

[pkh]

Podstawy to pewnie da się załapać tak w 2-4h. W większości przypadków wystarczy.

[Saly]

@olekturbo: nie, tworzysz nowe commity (lub nadpisujesz stare przy pomocy git commit --amend) i pushujesz na branch.

[szk6dnik]

@olekturbo: Robisz nowy commit, który zawiera poprawki. Dobrze by było dać w pierwszej linijce opisu commitu, że to zmiany wynikające z code review. @Saly ja się mocno nie zgadzam z robieniem --amend bez powodu. Czasem potrzeba więcej niż jednej osoby, żeby zaakceptować MR. Jak druga osoba może wyrazić swoją opinię skoro nie istnieje pierwotny commit? Co jeśli osoba, która chciała zmiany odejdzie z pracy? Przychodzi kolejna osoba i nie

[shpyo]

@olekturbo: Tak jak pisali poprzednicy. Tylko nie rób commitów typu: "cr fixes" XD. Pisz dokładnie do zmieniłeś. Polecam: https://highlab.pl/conventional-commits/

[Saly]

@szk6dnik: w czasie review to tak. Jak trzeba zmergowac PR, to wolę miec zesquashowane commity, żeby każdy commit coś wnosił. Nie lubie mieć commitów odnośnie review w kodzie, bo ciężko się pózniej czyta historię. Zresztą jak chcę przejrzeć review to wchodzę na stronę danego PR