#heheszki #humorinformatykow #programowanie
uwielbiam używać gita
Komentarze (13)
@redve tak samo robie, czasami daje "major changes" jak jest dużo xDD albo "general improvements"
@redve semantyka nie ma związku z ilością kodu jaki wrzucasz tylko jego działaniem. z grubsza to wygląda tak:
-
MAJOR version when you make incompatible API changes
-
MINOR version when you add functionality in a backward compatible manner
-
PATCH version when you make backward compatible bug fixes
@GrindFaterAnona o, warto wiedzieć
chyba, ze chodzi ci o ilosc zmian jak na jeden commit. to wtedy faktycznie ktos grubo przesadzil. z drugiej strony jest to normalne na wczesnych etapach projektu
Ja za to robię commit co zmianę w klasie. Potem w PR jest zmodyfikowane 13 plików i 80 commitów. Jakieś takie przywyczajenia z Quick Save w Duke Nukem 3D ;)
@Trawienny próbowałem tak kiedyś i to jest przegięcie w drugą stronę. Potem przy wprowadzaniu poprawek robienie rebase i amend często trwa więcej czasu niż rzeczywista zmiana (bo zmieniałeś np jeden znak). W przypadku zmian w klasach często też będą występować konflikty, bo zmiana w klasie może nieść za sobą zmiany w innych plikach w użyciach tej klasy. Spotkałem się też ze stylem commit na każdy plik, wtedy konfliktów raczej nie ma, ale wprowadzenie jakiejś jednej ogólnej zmiany powoduje kilka commitów.
Wniosek: commituj jak chcesz a potem przy mergu rób squasha xd
@redve - nie takie rzeczy człowiek widział czy nawet sam odpierdalał
Ja j⁎⁎ie, jak bym mógł to od razu reject na czymś takim.
Daj reviewerowi PR z 10 zmianami to znajdzie 4 błędy. Daj mu taki z 1000+ zmianami to nie znajdzie żadnego. Róbcie małe PR.
Yeah, to ja daję takie o nazwie "stuff I've been working on for past 3 months"
To nie jest śmieszne nic a nic, jak jeszcze chodziłem do biura to biłem kijem programistów co wrzucali więcej niż 500 linii zmian
Komentarz usunięty
kto reviewował takiego kloca 2k linii zmian ten w cyrku się nie śmieje.
Zaloguj się aby komentować