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ę. ( ͡° ͜ʖ ͡°)
#heheszki #programowanie #gownowpis #zalesie
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ę. ( ͡° ͜ʖ ͡°)
#heheszki #programowanie #gownowpis #zalesie
Klasyczne: it depends.
Jeżeli każdy jeden commit sensownie ma opisane co on robi i dlaczego on to robi to takie review to przyjemność.
Ale sądząc po frustracji to historia zmian to:
Stuff
More stuff
Oh...now it works
Adding file
Ooops, removing file
To slabo. Bardzo slabo.
Jeżeli historia zmian to smietnik, squashuj w cholere. I tak nic nie wyciągniesz.

@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ąć.
@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.
Zaloguj się aby komentować