Siema. Zastanawiam się kiedy robić commity.
Załóżmy, że napiszę komponent to powinienem go od razu z commitowac?. Wiem, że jeszcze z 100 razy go zmiennie, i za każdym razem commitowac to niezły bajzel się tam zrobi.
Z drugiej zaś strony jak nie z commituje a wykorzystam go gdzieś w aplikacji, to jak kiedyś będę chciał się cofnąć będzie go brakować.
Kiedy wy commitujecie?, Jakieś ciekawe artykuły na ten temat?. Jakieś rady?.
Pozdrawiam.
Po to są commity żeby właśnie bajzlu nie było.
Możesz mieć i ze 100 commitów na branchu, jaki to bajzel? Problem jest dopiero wtedy, gdy ciągniesz brancha tak długo, że pojawiają się konflikty.
Ja staram się komitować tak, że jeden commit to najmniejsza jednostką pracy, której nie chciałbym odtwarzać. Próbuję też aby jeden commit był spójny, to znaczy coś zmieniał lokalnie, np. jedną funkcję, itp. Staram się też by commit dawał kod, który da się skompilować, ale jeśli to prywatny branch to czasem po prostu wrzucam jak leci.
debug napisał(a):
Ogólnie to jest na razie moje lokalne repo. Ale kiedyś w przyszłości będę chciał je wypchnąć na hub'a i nie chciałbym, żeby tam było miliard bezsensownych commitów.
Dlatego commity się squashuje, rebasuje itd Można squashować automatycznie przed merdzie z pomocą githuba. Można squashować ręcznie z konsoli za pomocą komendy git rebase -i
BTW dobrze żebyś lokalne repo jak najszybciej wypchnął gdzieś bo jak padnie Ci dysk to wszystko stracisz
JavaScript 
React 
Git 
git rebase master
bo jak padnie Ci dysk to wszystko stracisz zanim mi w pracy ogarną nowego, to pewnie nie ma co płakać nad tymi 1-2 dniami poświęconymi na task xd
Punkty 4, 9 i 12 mogą być wielokrotne.
W międzyczasie mogę wpaść też na inne sposoby implementacji, wtedy tworzę następną gałąź i poszczególne etapy commituję do niej.
Lekcje na dziś:
oprócz tego, co przedmówcy pisali (o squashu itp.), to jeszcze fajne jest git add -p NAZWA_PLIKU, bo wtedy można sobie wybierać, które linijki z danego pliku mają iść do commita, które nie (bo np. są jakimiś naszymi eksperymentami, których jeszcze nie chcemy commitować).
W projektach własnych - co chwilę. W pracy natomiast przyjmowana jest taktyka 1 task = 1 commit (ewentualnie kilka, jezeli coś wyjdzie przy code review, lub zakres implementacji jest bardzo duży, a jego częściowe commity udrożniają drogę do realizacji user story.
Belka napisał(a):
W projektach własnych - co chwilę. W pracy natomiast przyjmowana jest taktyka 1 task = 1 commit (ewentualnie kilka, jezeli coś wyjdzie przy code review, lub zakres implementacji jest bardzo duży, a jego częściowe commity udrożniają drogę do realizacji user story.
Jakie znaczenie przy code review ma to, czy był jeden czy więcej commitów?
somekind napisał(a):
Jakie znaczenie przy code review ma to, czy był jeden czy więcej commitów?
Chodziło mi bardziej o to, że jeżeli po code review okazuje się, że coś należy poprawić, to dochodzą commity poprawkowe.
Ale napisałeś, że 1 task to 1 commit. Jakie to ma znaczenie przy review, czy task był jednym czy tysiącem commitów? Przecież nie przegląda się każdego po kolei, tylko różnicę między masterem a gałęzią z danym taskiem.
Nie mam żadnej sztywnej reguły, generalnie staram się, by jeden commit zawierał jakiś spójny zestaw zmian. Czy to będzie cały task naraz (jak zadanie jest proste, to czemu nie), czy jeden krok z 20, ma już mniejsze znaczenie. Czasami więc commit może zawierać kilka godzin pisania, usuwania i ogólnego dłubania, a czasami zawiera tylko kilkusekundową zmianę nazwy czegoś.
Ogólnie to popieram przedmówców - jak przełamie się lody i nauczy, jak używać git rebase --interactive, to wtedy można commity robić praktycznie co chwilę, a potem na koniec pracy (czy też przed wepchnięciem do repo) sobie przejrzeć listę i jeżeli wydaje się, że część commitów jest za mała, to je połączyć.
za każdym razem gdy czuje że to co jest zrobione jest warte zapisaniato ja bym nigdy nie commitował :D