Wpis z mikrobloga

Po przeczytaniu posta z gorących tak mnie naszło.
Jaka jest zaleta wielu commitów per jeden pull request?
Bo chyba nie chęć poznania czyjegoś toku rozumowania?

Powrót do jakiegoś stanu w środku implementacji?
Jeszcze nigdy nie spotkałem się z tym, aby ktoś chciał wrócić do jakiegoś momentu implementacji.
#programowanie #it
  • 15
@Cogres: optymalnie to jak dla mnie kilka do kilkanaście, ale czasem zdarza się i kilkadziesiąt - wolę więcej małych i prostych zmian niż jedną a dużą i przez to skomplikowaną
@Cogres: Jak dla mnie to chyba tylko robienie syfu na masterze ( ͡° ͜ʖ ͡°)

Wiele teamów ma nawet praktykę żeby w momencie merge'a do mastera wszystkie commity się squashowały, tj. łączyły w jeden duży z nazwą tego właśnie pull requesta. GitLab ma nawet do tego specjalną funkcję która automatyzuje ten proces.
@Cogres: Oczywiście robienie wielu małych commitów w trakcie implementacji ma jak najbardziej sens. Chociażby po to że jak w którymś momencie coś namieszamy i popsujemy, to zawsze można się cofnąć tylko kawałek w gicie a nie do samego początku. Tak jak savewowanie w grach :v
@Calosija: jeżeli chodzi o możliwość cofnięcia to zawsze wiem co robię i wiem kiedy będę potrzebował możliwości cofnięcia się. Wtedy oczywiście commit. Ale tutaj z tego co rozumiem autorowi chodziło o wymuszenie robienia kilku commitów w trakcie implementacji.

Wiele teamów ma nawet praktykę żeby w momencie merge'a do mastera wszystkie commity się squashowały, tj. łączyły w jeden duży z nazwą tego właśnie pull requesta


@Calosija: dokładnie tak też wydaje mi
@Cogres: Zależy jak sie ludzie dogadają w teamie. Jedni lubią tak, inni inaczej. Ważne, że jak są akurat ustalone dobre praktyki, to wszyscy muszą się ich trzymać. Lead np. może chcieć zobaczyć, czy pierwszym commitem były testy, czy kod ;)
Najczęściej spotykany jest połączony jeden commit per task i tu zależy, może pull request idzie z całą funkcjonalnością, wtedy na pewno będzie więcej.
Co drużyna, to i tak robi po swojemu.
@Cogres: IMO commity są atomicznymi, znaczącymi zmianami w historii danej gałęzi. Z założenia każdy atomiczny commit ( przynajmniej taki wypchnięty spoza lokalnego repozytorium ) powinien wnosić dodatnią wartość dla danego projektu ( czytaj nie psuć go, nie wypuszczać pół commitów etc ).

Odpowiadając na Twoje pytanie, wiele commitów oznacza wiele takich punktów z znaczącymi zmianami w obrębie scope-u danej gałęzi. Czyli np tworzysz ficzer, którzy składa się z A, B i
@alex-fortune: jeżeli pracujesz na kilkoma rzeczami, które mogą działać niezależnie to jak najbardziej powinny mieć swoje osobne commity.
Ale takie raczej nie powinny się znaleźć w obrębie jednego pr. Tzn, że coś jest nie tak z procesem definiowania zadań.
Jestem sobie w stanie wyobrazić, że ktoś robi kilka rzeczy na raz w czasie pracy na jednym zadaniem i wystawia to jako jeden commit.
@Cogres: 1. Chęć poznania toku rozumowania - często zdarza mi się, że muszę wyjaśniać czemu zbudowałem coś w taki, a nie inny sposób. Wtedy bardzo pomaga odniesienie się do jakiegoś poprzedniego commita, pokazanie jak już próbowałem to rozwiązać i czemu nie wyszło.
2. Wszystko zależy od praktyk w firmie, wielkości projektu, ilości deweloperów.
U mnie mamy zasadę, że tworzymy PRy już na samym początku pracy z danym taskiem i staramy się
patrzysz osobno na poszczególne commity w pull requeście?


@Cogres: Tak

Raczej na zbiorczy widok całości tego co zostało w nim wystawione.


@Cogres: Zbiorczo też patrzę. Ale przeglądam po kolejnych commitach. Oczekuję, że będą małymi, sensownymi, atomowymi zmianami. Żeby łatwo było zauważyć na czym polega zmiana.

Patrząc na widok po całości nie zauważysz, że gdzie kolega zrobił błąd – pomylił się gdzieś, zapomniał o czymś, przeoczył coś, źle zrefaktorował (nie wszystko