[anonim1133]

Jak szczegółowe zmiany powinno się zawierać w #git, aby to miało sens?

Każda nawet drobna poprawka to osobny commit, czy kilka drobnych zmian zbijać w sumaryczny commit?

Wydaje mi się, że najrozsądniej jak najmniejsze porcje commitować, łatwiej potem będzie ewentualnie coś ogarnąć?

Mirki z #programowanie, jakies hinty?

[s.....r]

@anonim1133: IMHO do kilku commitów w przeciągu godziny, jakaś nowa funkcja, elementy interfejsu itp. Czyli stosunkowo wysoka częstotliwość, tak też mi mówiono.

Oczywiście bez przesady w drugą stronę, nie będziemy commitować w końcu pojedynczych linii (chyba że ultraważne typu referencje do jakichś serwerów).

[ciepol]

@anonim1133: chyba najlepiej powiązać ticket z commitem.

[anonim1133]

@super: Czyli jednak jakieś pierdoły zbijać z resztą? Nie utraci się wtedy na czytelności takich commitów?

[m_bielawski]

@anonim1133: jeden commit = jeden temat. Nawet jeżeli zmieniłeś tylko jeden znak, to jest to samodzielna zmiana. Dajesz tytuł "Fixes XXX" i wiadomo skąd ta zmiana znaku i w drugą stronę - wiadomo co zostało zrobione, żeby naprawić XXX.

Jak piszesz większy feature, to robisz brancha i commitujesz w nim kolejne kroki ("Creates controller Y", "Implements method Z", "Refactors library W", oczywiście z trochę dokładniejszym opisem :P)

[GrinDeN]

@anonim1133: @ciepol dobrze mówi - jeden commit do jednego zgłoszenia, wtedy potem przy ewentualnej wpadce wiesz co, gdzie i jak.

[dagon_666]

To zalezy, pojedyncze zmiany typu bugfixy, drobne korekty, commituje osobno. W ten sposob latwo jest cos dodawac do innych branchy(cherry-pick), oraz latwo revertowac zmiany. Jezeli chodzi o nowe featury to zawsze rozwijam na osobnej branchy, a potem merguje, ewentualnie rebase przed mergem a potem i tak non-fast-forward merge tylko po to, zeby miec merge commit, ktorego w razie jakichs zmian decyzji odnosnie funkcjonalnosci, tez latwo jest sie pozbyc.

[kamdz]

@anonim1133: jeden z moich wykładowców kazał commitowac każdą zmianę, nawet jednolinijkową

[ciepol]

@kamdz: myślę, że opinie wykładowców są tymi, którymi powinno się najmniej przejmować ;-)

[anonim1133]

@dagon_666: @m_bielawski: To mi się podoba, brzmi sensownie. Dzięki panowie!

[msrk]

@kamdz: który niby?

[m_bielawski]

@ciepol: akurat w tym jednym wypadku można się go posłuchać ;P

@anonim1133: staraj się po prostu trzymać porządek w tych commitach. Wrzucanie kilkunastu małych fixów do jednego commita sprawia, że potem nie wiesz nawet co napisać w treści i powstają potworki typu "Lots of changes" albo "Various bugfixes".

[anonim1133]

sprawia, że potem nie wiesz nawet co napisać w treści i powstają potworki typu "Lots of changes" albo "Various bugfixes".

@m_bielawski: Prawda!

Jednocześnie trochę głupio mi było dodawać commit jak wystarczyło gdzieś poprawić jedną linijkę, którą wcześniej przeoczyłem ;f

[m_bielawski]

@anonim1133: jak chcesz poprawić ostatni commit (zanim go pushniesz gdzieś!), to możesz użyć

git commit --amend

[dagon_666]

@anonim1133: poczytaj sobie o gerricie - system, ktory wiaze kazda zmiane razem z code review w ten sposob masz jednoczesnie w logu informacje o review i ewentualnie w gericie powiazanie do ticketa.

[anonim1133]

@m_bielawski: a widzisz. Swego czasu próbowałem czytać co z czym. Było chyba o wszystkim, ale o tak podstawowej funkcji nigdzie nie było...

[safjanowski]

@anonim1133: Na branchu rozwojowym wiele commitów, a następnie przy mergu do głównego brancha

git merge future_branch --squash; git commit -am

oraz zasada pisania komentarzy:

task-id krótki opis do