Ostatnio przeglądając GitHuba natknąłem się na osoby robiące kilkadziesiąt commitów dziennie, w każdym zmiana typu "dodałem/zmieniłem cośtamcośtam" , a w kodzie dodane/usunięte 2 linijki... Czy ludzie naprawdę commitują dla statów na profilu?
0
0
Chyba lepiej tak niż za jednym commitem przepisać całą aplikacje.
0
BartoszCoyote napisał(a):
Chyba lepiej tak niż za jednym commitem przepisać całą aplikacje.
Ja uważam, że liczy się postęp, jeśli po np. 200 commitach aplikacja ma jedną dodaną funkcję to ewidentnie coś jest nie tak.
0
Ale co w tym złego? Przecież jeśli zmiana jest jednostkowa to taka powinna być.
Sam tak robię, poprawiam coś, commit, poprawiam coś innego, commit itp itd
Edit:
@Uncle Sam
Nie znam sytuacji za bardzo, ale mam doświadczenie z sytuacją odwrotną - ktoś wrzucał megacommity i potem trzeba było robić antycommity, zamiast po ludzku wrócić do poprzednich wersji.
3
Wrzuca sie całe spójne jednostki. Jeśli fix dla jakiegoś buga to była jedna linijka kodu to commit ma 1 linijkę.
2
W pracy zespołowej lepsze są małe commity (oczywiście zachowując dobre opisy commitów), ale w przypadku hobbystycznych projektów można sobie robić co się chce, bo i tak terminy nie gonią, a nikt inny nie musi być na bieżąco z tym co robimy.
Ostatnio w moim hobbystycznym projekcie robiłem commita półtorej miesiąca i przepisałem nim połowę kodu: https://github.com/tarsa/SortAlgoBox/commit/34ff7f432c6338200c9755815ee7463a62348ecd
Zmiana jest fundamentalna, bo dotyczy podstawowej funkcjonalności w projekcie czyli sposobu organizacji zarządzanych buforów i agentów (wyjaśnienie terminologii nie jest tutaj ważne). Alternatywą mogłby być:
- wykasowanie starego rdzenia aplikacji, wstawienie zaślepek tak by kod się kompilował i zaczęcie od nowa lub
- tworzenie osobnego rdzenia aplikacji obok istniejącego, a na końcu wyrzucenie starego i zostawienie tylko nowego
Stwierdziłem jednak, że wymiana rdzenia aplikacji w jednym kroku będzie oznaczać mniejszy nakład pracy, a nikt na tym nie straci, bo jak na razie nikt inny ze mną nad tym projektem nie współpracuje. W innym przypadku takie podejście mogłoby być niedopuszczalne.
Miałem taki przypadek w firmie, że gość robił coś na branchu przez chyba 9 miesięcy i nie wciągał zmian z głównej gałęzi. Potem się zwolnił, a my musieliśmy to łączyć z głównym kodem. Była to dla nas nauczka, by rozbijać duże zadania na małe, które można dowozić regularnie. Regularne dowożenie małych zmian ma też te zalety, że można je na bieżąco testować, a także się z nimi płynnie synchronizować jeśli przy okazji w danym projekcie jest robione inne zadanie.
0
Chodziło mi bardziej o takie rozdrobnione commitowanie, bo niektórzy chyba na siłę robią commity nic nie wnoszące - żeby było, że coś zrobiłem ;)
P.S "3,942 additions and 2,817 deletions" nieźle ;)
0
czasami zmiana jednej klasy zmienia 500 podstron, niby mały commit ale duży :)
0
Uncle Sam napisał(a):
Chodziło mi bardziej o takie rozdrobnione commitowanie, bo niektórzy chyba na siłę robią commity nic nie wnoszące - żeby było, że coś zrobiłem ;)
To zależy od zmiany. Jeśli ktoś pracuje nad jednostkowym feature'm to może takie rozdrobnienie rzeczywiście może oznaczać problem.
Jeśli np. robi refactoring to jednak wolę commit/refaktorowany kawałek