Kiedy robić commity.

0

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.

3

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.

9

Ja tam commituje za każdym razem gdy czuje że to co jest zrobione jest warte zapisania. Na koniec i tak jak wystawiam pull req. to robie squasha i wszystko trafia do jednego commita.

4

Ja bym się ilością commitow tak nie przejmował, ważniejsze, żeby branch jak najkrócej żyła.

0

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. Ale chyba faktycznie za bardzo się tym przejmuje.

3
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

2

@debug: wypchnij to repo do sieci. Teraz wszyscy dostawcy oferują prywatne repozytoria. A commity? Nikt nie będzie ich przeglądać. Istotne jest żeby główny branch zawierał coś co działa.

3
  1. Gdy utworzę strukturę klas.
  2. Gdy utworzę strukturę testów.
  3. Gdy napiszę ileś testów.
  4. Gdy dopiszę brakującą infrastrukturę testów.
  5. Gdy napiszę resztę testów.
  6. Gdy zrefaktoryzuję testy.
  7. Gdy zacznę implementować kod.
  8. Gdy kilka testów przejdzie.
  9. Gdy więcej testów przejdzie.
  10. Gdy wszystkie testy przejdą.
  11. Gdy zacznę refaktoryzację kodu.
  12. Gdy będę w trakcie refaktoryzacji kodu.
  13. Gdy skończę refaktoryzację kodu.
  14. Gdy przejrzę wszystko na koniec i posprzątam jakieś śmieci, które zostały.

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.

6

Lekcje na dziś:

  1. Branch
  2. Squash
  3. Merge/rebase
7

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

1

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.

1
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?

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

1

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.

0

Wg mnie wystarczy commitowac raz dziennie przed 17 ;)

4

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

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