Częstotliwość commitowania?

Pytanie co najmniej bezsensowne, ale utknęło mi w myślach i nie mogę się go pozbyć.

Słyszałem wielokrotnie, że commity powinny być jak najczęstsze, a w każdym z nich powinna znajdować się jak najmniejsza liczba zmian.

Przy moim aktualnym projekcie postanowiłem sobie wreszcie wziąć do serca te rady. Wynik tego taki, że znacznie łatwiej mi się wymyśla, co mam napisać w opisie commita. Do tej pory zwykle robiłem w ciągu 2 godzin maksymalnie 6, 7 commitów (nie liczę szybkich fixów), a teraz wyliczyłem ich aż 12... na pół godziny. Za każdym razem, gdy wysyłam kolejnego commita, poprzedni wyświetla mi się jeszcze jako "1 minute ago".

Pytania do was:
Przesadzam? A może dalej zbyt powoli?
Jak często wy commitujecie? W jakich sytuacjach?

Ja commituję rzadko, ale to przyzwyczajenie z tfsa. Swoją drogą, niektórzy robią tak, że najpierw wpisują wiadomość do commita, a dopiero potem kodzą zmiany.

O takim rozwiązaniu też słyszałem. Ja bym tak nie potrafił, często zmieniam w trakcie pisania koncepcje. Korzystam z dekstopowego klienta GitHuba, więc w razie potrzeby mogę "odznaczyć" te pliki, które miały być wysyłane w oddzielnym commicie.

ja mam takie myśli:

• commituj tak często, żeby jak ci się coś spieprzy mógł cofnąć zmiany do poprzedniego commita i nie cierpiał zbytnio (czyli trochę jak pytanie o robienie kopii zapasowych).
• commituj na tyle małe commity, żebyś nie musiał rozwiązywać tony konfliktów, jak będziesz potem chciał coś zmerdżować.
  (jak zmieniasz w tym samym czasie pliki A, B i C a są to niezwiązane logicznie ze sobą zmiany - to często lepiej zrobić commit samego pliku A, potem pliku B, potem samego C, niż pakować do jednego commita A,B,C a potem mieć problem, kiedy trzeba bedzie cofnąć, albo likwidować konflikty.

EDIT: ale adekwatnie: często lepiej mieć commita, który obejmuje ileś plików, jeśli robisz coś, co jest powiązaną ze sobą całością. Np. refaktoryzujesz jakąś klasę, z której korzystają pliki A, B, C, to wypadałoby wszystkie te pliki scommitować, które musiałeś zmodyfikować.

• jeśli pracujesz w zespole to możesz mieć napaćkane commitami co minutę, ale zanim coś popchniesz na gałąź produkcyjną/developerską, to lepiej zesquashować (zrobić z iluś commitów jeden), dla dobra innych programistów. (to się przynajmniej sprawdza przy korzystaniu z Gita, gdzie każdy ma swoją osobną kopię repozytorium).

A może.... po prostu, tadam tadam [tutaj grają trąbki, taki nastrój - że niby nadchodzi jakiś mesjasz czy coś] zrobisz ribejza: http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html .

Chodzi o to że git ma Ci pomagać a nie wprowadzać jakie wyimaginowane "zasady", robisz commitów tyle ile Ci się podoba, żeby potem cofać zmiany, robić cherry picka etc. ale na sam koniec i tak wychodzi jeden "Zrobiłem cośtam / ISSUE jakieś tam / nawet napisałem test"

Ja robię commity po ukończeniu danego taska. Taski rozbijam sobie na możliwe małe elementy, które CZEMUŚ SŁUŻĄ. Na przykładzie webdev: np. samo wyświetlenie (w panelu administracyjnym) listy klientów to jest jeden task. Dodawanie nowego klienta to drugi task. itd. Jeżeli dodawanie klienta łączy się z innymi zadaniami (np. weryfikacja danych firmy na podstawie NIPu przez zewnętrzne API) - to zadanie wydzielam już jako osobne - i pierwsze commituję wersję bez tego. Drobne poprawki, które wychodzą w międzyczasie - np. zmiana koloru podświetlenia elementu, złe marginesy, itd - zazwyczaj zawieram razem z commitem jakiegoś taska - z wyjątkiem sytuacji, gdy tych poprawek jest bardzo dużo (bo np. miałem zapisane "na potem") - wtedy popraweczki mają swój osobny commit.

Nie stosujecie u Was w firmie code-review? U nas jest praktyka by każdy zakończony task wrzucić do code review. Po zaakceptowaniu przez 2 osoby można dopiero kod wrzucać. Czyni to niemożliwym wrzucanie kodu co 30min. Najczęściej raz dziennie, ale czasem i nawet rzadziej - czasem krótkie taski długo zajmują.

Z drugiej strony jeśli czujesz potrzebę częstego commitowania i posiadania historii zmian dobrym rozwiązaniem może być GIT i lokalne commity.

Commitujesz na swojej galazce jak uwazasz ze zrobiles kolejna wersje ktora w jakis sposob jest lepsza od poprzedniej (np. cos dodales, albo cos zaczelo dzialac) i dopiero jak chcesz dolaczyc zmiany ze swojej galazki do glownego brancha to robisz review.

Ja tam robię gałąź per task, commituję do niej, gdy uda mi się napisać sensowny i kompilujący się kawałek kodu, np. jedną warstwę. Jak skończę taska, to robię merge do głównego brancha (develop/trunk w zależności od typu zdalnego repo) i squashuję. Historia w głównym branchu jest czytelna, ja z kolei zawsze mogę się cofnąć do poprzedniej działającej wersji.
Częstotliwości nie liczę, bo jest niemiarodajna.

W jednym projekcie robiłem tak jak opisał somekind.
Wyglądało to mniej więcej tak (pisane z palca).

# feature - branch do relese-u
git merge master
git checkout master
git checkout feature -- 
# tu mamy kod z feature ale nadal pozostajemy na master!
git commit -a -m "Feature title"