[PolishPsycho]

#programista15k #programowanie #heheszki

[nad__czlowiek]

@PolishPsycho: ten pierwszy pisze sensowne i działające rozwiąznaia

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 ( ͡°( ͡° ͜ʖ( ͡° ͜ʖ ͡°)ʖ ͡°) ͡°)

[relationbrewingarea]

@nad__czlowiek 307, a nie 5. Ale generalnie liczba commitów to jeszcze gorsza metryka niż liczba linijek kodu.

[sopelas]

@nad__czlowiek no właśnie dlatego jest SHE?

[ukradlem_ksiezyc]

@nad__czlowiek:

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".

C--j, ż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

[repro5]

@PolishPsycho: Przestałem na to zwracać uwagę. Każdy ma inne zadanie, więc w żaden sposób nie jest to mierzalne. Można zwrócić uwagę na jakość tych commitow.

[e.....p]

@ukradlem_ksiezyc: co to za idea? Chodziło ci o rebase zamiast mergea chyba?

[ukradlem_ksiezyc]

@elvp:

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

[Nie_bo_ty]

@nad__czlowiek: jprdl jaka grypsera

[Krolik]

@ukradlem_ksiezyc: akurat takie rzeczy jak "changed class name" i inne refaktoringi to właśnie dobrze zostawiać jako osobny commit, bo potem jak robisz jakikolwiek merge / rebase to o wiele łatwiej scalić zmiany kiedy refaktoringi masz w osobnych commitach. Nie mówiąc o tym że wtedy też łatwiej jest recenzować pozostałe zmiany bo widzisz samo mięsko. Duże commitynie działają też dobrze przy bisekcji - znajdujesz buga w commicie na 10 tys. linii

[ukradlem_ksiezyc]

@Krolik:
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.

[Krolik]

@ukradlem_ksiezyc: No dobra, ale tak serio to w czym Ci przeszkadzają małe commity? Małe commity nie mają żadnych wad bo zawsze można z nich zrobić większe. Z dużego nie zrobisz z powrotem małych bo straciłeś informacje.

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

[ukradlem_ksiezyc]

Małe commity przeszkadzają w ogólnym rozumieniu co się dzieje. Tracisz duży obraz zmian na rzecz małych, nic nie znaczących. I dodatkowo cały log zawalony tymi commitami że trudno później znaleźć co do czego było. Po miesiącu czy jakimś czasie sami autorzy nie pamiętają dokładnie o co chodziło.

[Krolik]

Małe commity przeszkadzają w ogólnym rozumieniu co się dzieje.

@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.

I dodatkowo cały log zawalony tymi commitami że trudno później znaleźć co do czego było

To że nie możecie czegoś znaleźć to nie jest kwestia wielkości commitów tylko braku standardu w ich nazywaniu.