Ehhh, pull request na 25 plików i 42 commity... co ci juniorzy to ja nie wiem. A potem płacz, że AI zabiera pracę. (

@Ragnarokk Tak... Wtedy bym nawet nie próbował przeglądać. ( ͡°( ͡° ͜ʖ( ͡° ͜ʖ ͡°)ʖ ͡°) ͡°)

@LondoMollari This guy ITis.

@owczareknietrzymryjski - to już zależy od przyjętej konwencji w zespole

@koszotorobur Na przykład konwencja burdelowa na to pozwala

@ataxbras - ba, ona to wymusza

@Swbd squashuj, a potem przejrzyj co się da wyciągnąć w autonomiczne commity i podziel zgodnie z zakresem, a nie progresem. Wrzucanie wszystkiego w jeden commit to też antypattern, bo utrudnia troubleshooting. Kto chociaż raz musiał użyć git blame, git bisect czy git revert ten wie.

@lurker_z_internetu ależ oczywiście. Ale IMO to reviewer powinien prosić o taki podział a nie robić to sam.

Reviewer nie powinien osobiście ingerować w historie. A sugerować, typu Ej tu wprowadzasz zmianę a dwa commity dalej ja fixujesz bo była źle na początku. Interaktywny rebase jest mega potężny żeby to osiągnąć.

@Swbd nie no pewnie, to co opisałem to robota dla autora. Reviewer powinien wymagać takich zmian zanim zaakceptuje. Junior się nastęka, ale się nauczy czegoś.

@Czokowoko fan SVN

@lurker_z_internetu kurde, skąd wiedziałeś? XD

@Czokowoko bo studenci tak się uczą wersjonować swoje prace:

* gotowe.jpg

* gotowe_poprawki.jpg

* gotowe_poprawki_final.jpg

* gotowe_poprawki_final_FINAL.jpg

Potem niektórzy odkrywają, że SVN rozwiązuje dla nich problem głupich nazw plików przerzucając go na problem głupich nazw commitów. Commitów i tak nikt nie czyta, bo zazwyczaj pracują nad projektami sami.

Przejście na git wiąże się z wdrapanien na pewien learning curve. Jest dramatycznie lepszy, ale zasadniczo różny. To samo tyczy się nauczycieli i opiekunów legacy code niestety.