Aktywne Wpisy
DrCieplak +451
"Mąż zarabia 20 tys a ja 4 tys, dwa lata temu KUPILIŚMY dom". #p0lka
Itslilianka +15
Jadę oglądać moje wymarzone auto z czasów dzieciństwa. (。◕‿‿◕。) Na co zwracać uwagę? Nie mogę się doczekać aż usiądę za kółkiem #motoryzacja
ten drugi robi 5 commitów dziennie gdzie jeden commit to zmiana typu literówka
Gościowi na dole pasowałoby wytłumaczyć na czym polega squashowanie commitów przed wypchaniem ich do remote brancha ( ͡°( ͡° ͜ʖ( ͡° ͜ʖ ͡°)ʖ ͡°) ͡°)
Pewnej grupie ludzi nie wytłumaczysz, bo oni w tej sposób "zachowują historię zmian i każdy może prześledzic ich rozumowanie".
#!$%@?, że później w logu nic nie możesz znaleźć bo commit messages brzmią np: "Changed class name". Dodatkowo taka osoba może powiedzieć, że zrobiła 20 commitów a ty jeden, więc jest lepszy.
EDIT:
A spróbuj
To trochę też zależy co i jak chcesz. Jeśli projekt nie jest duży, to squash i rebase na masterze, zamiast wypychania nowej gałęzi - zaletą jest jedno proste drzewo.
Jak robisz duży feature (albo w kilka osób) to jednak dużo lepszym wyborem jest branch
Niestety o wiele częściej spotykam się ze zwolennikami absurdalnych commitów niż ich squashowania.
A debugging nigdy mnie nie przerażał. Lubię debugować - nie ważne co. Więc commit na 10k linii to nic strasznego.
Co do debugowania to ja debugowałem projekty mające setki tysięcy linii plus miliony linii w zależnościach, ale jak masz dobrą historię podzielona na małe zmiany to często w ogóle nie trzeba nic debugować. Bo jak
@ukradlem_ksiezyc: Ale do ogólnego rozumienia dużych zmian to historia gita nie służy. Od tego macie narzędzie do zarządzania projektem.
To że nie możecie czegoś znaleźć to nie jest kwestia wielkości commitów tylko braku standardu w ich nazywaniu.