Częstotliwość commitowania?

Odpowiedz Nowy wątek
2014-12-02 20:13
0

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?


Pozostało 580 znaków

2014-12-02 20:18
1

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.

Pozostało 580 znaków

2014-12-02 20:21
0

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.


Pozostało 580 znaków

2014-12-02 20:22
3

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

((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
edytowany 1x, ostatnio: LukeJL, 2014-12-02 20:25

Pozostało 580 znaków

2014-12-02 21:18
2

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/[...]hing-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"


"Perhaps surprisingly, concurrent programming isn’t so much about threads or
locks, any more than civil engineering is about rivets and I-beams."
edytowany 1x, ostatnio: niezdecydowany, 2014-12-02 21:19

Pozostało 580 znaków

2014-12-03 10:08
3

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.


Pozostało 580 znaków

2014-12-03 11:05
0

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.

Pozostało 580 znaków

2014-12-03 11:18
4

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.

Pozostało 580 znaków

2014-12-03 12:42
2

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.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2014-12-03 13:49
0

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"

Jeśli chcesz pomocy, NIE pisz na priva, ale zadaj dobre pytanie na forum.
edytowany 1x, ostatnio: MarekR22, 2014-12-03 13:50

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0