Kiedy robić commity.

Odpowiedz Nowy wątek
2020-07-04 14:03

Rejestracja: 3 lata temu

Ostatnio: 13 godzin temu

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.

Pozostało 580 znaków

2020-07-04 14:13

Rejestracja: 4 lata temu

Ostatnio: 8 godzin temu

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.

Pozostało 580 znaków

2020-07-04 14:21

Rejestracja: 4 lata temu

Ostatnio: 4 godziny temu

Lokalizacja: Lublin

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.

za każdym razem gdy czuje że to co jest zrobione jest warte zapisania to ja bym nigdy nie commitował :D - Pinek 2020-07-08 15:59

Pozostało 580 znaków

2020-07-04 14:24

Rejestracja: 3 lata temu

Ostatnio: 6 godzin temu

4

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


Pozostało 580 znaków

2020-07-04 15:02

Rejestracja: 3 lata temu

Ostatnio: 13 godzin temu

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.

Pozostało 580 znaków

2020-07-04 15:41

Rejestracja: 1 rok temu

Ostatnio: 3 godziny temu

Lokalizacja: Silesia

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


wszystko zalezy od dynamiki zmian, squash powoduje niepotrzebne konflikty. - mr_jaro 2020-07-04 20:32
możesz rozwinąć bo nierozumiem? jak robie squash na swojej własnej gałęzi to żadnych konfliktów nie ma, a dzięki temu że mam tylko jeden commit łatwiej zrobić git rebase master - KamilAdam 2020-07-04 20:34
Tak sobie myślę... 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 - Pinek 2020-07-08 16:01

Pozostało 580 znaków

2020-07-04 19:09

Rejestracja: 4 miesiące temu

Ostatnio: 1 godzina temu

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.


Pozostało 580 znaków

2020-07-06 01:36
Moderator

Rejestracja: 12 lat temu

Ostatnio: 5 godzin temu

Lokalizacja: Wrocław

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.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
Wygląda prawie jak jakiś poemat - Pinek 2020-07-08 16:01

Pozostało 580 znaków

2020-07-06 01:54
Moderator

Rejestracja: 16 lat temu

Ostatnio: 5 godzin temu

6

Lekcje na dziś:

  1. Branch
  2. Squash
  3. Merge/rebase

Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
edytowany 1x, ostatnio: Shalom, 2020-07-06 01:54
Nawet nie sam squash, ale całe interactive rebase, które pozwala również podzielić commity na mniejsze - hauleth 2020-07-06 13:37
Ale to już level hard, na początek squash wystarczy ;) - Shalom 2020-07-06 13:39
To jeszcze można dodać git commit --fixup=<hash> oraz git rebase -i --autosquash - hauleth 2020-07-06 13:40

Pozostało 580 znaków

2020-07-06 02:50

Rejestracja: 6 lat temu

Ostatnio: 20 minut temu

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


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);

Pozostało 580 znaków

2020-07-13 23:15

Rejestracja: 3 lata temu

Ostatnio: 2 godziny temu

Lokalizacja: PL

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.

Pozostało 580 znaków

Odpowiedz

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