Git - czy warto uzywac merge and squash?

Witam,

Jakie jest wasze zdanie pomiedzy megowaniem bez zadnych dodatkowych opcji merge vs merge and squash?

Mi mega sie nie podoba, ze opcja merge and squash zmienia autora kodu do autora, ktory zrobil merge and squash. Czyli mamy branch nad ktora pracuje 2-3 osoby, ale i tak caly kod bedzie przypisany do osoby ktora zrobila merge and squash. Czyli obniza to mega statystyki dla reszty grupy. Nie wiem czy w poszczegolnych fimrach sprawdza sie wydajnosc developera. Jezeli tak to czy jest to np skladaowa, ilosci popchnietych linii kodu oraz comiitow. Czy jest to np ilosc ukonczonych ticketow/taskow? Ale nie lubie tej opcji. Ponad 5000 linij kodu. Kilkad tygodni pracy a mnie nawet nie ma w repozytorium :[ Jak bym w ogole nad tym nie pracowal. Ladnie ktos sobie to obmyslil.

Panie, jak taki wyścig szczurów masz w pracy to współczuję. Po pierwsze to jakie to ma znaczenie czyje imie się tam znajdzie? Jeśli jesteście oceniani po ilości commitów czy napisanych linii kodu to proponuję znaleźć mniej absurdalne i faszystowskie miejsce pracy. Po drugie jeśli w ramach jednego ticketa/story piszecie po 5k linii kodu to coś Wam leży na etapie planowania pracy.

Kilkad tygodni pracy a mnie nawet nie ma w repozytorium
Kilka tygodni pracy kończące się jednym commitem do repo? Nieźle...

W ogóle wspominasz te statystyki co jest dosyć smutnym obrazem bo wychodzi na to że traktujesz taki wyścig szczurów jako coś normalnego. W historii repo nie chodzi o to aby można było łechtać swoje ego i udowadniać managerom jakim się jest dobrym pracownikiem, tylko o to żeby było jasne co i kiedy się zmieniło.

Swoją drogą to zła kategoria forum- co to ma wspólnego z PHP?

@Aventus Fakt, kategoria zla. Ale teraz nie widze opcji na jej zmiane.

To nie chodzi o wyscic szczorow. Niby to tylko numerki, ale jak patrze na statystyki i widze, ze z nich wynika ze w ostatnie miesiace praktynie nic nie zrobilem to troche to boli. Bo tak nie jest. Ja pracuje w firmie nad jednym duzym projektem. I taki epic jest rzadkoscia, ale zdarza sie. Nie ma innej opcje. Przebudowalismy jedna z instniejacych funkcjonalosci, ktora jest uzyta niemal, ze wszedzie na aplikacje, ale nie w tym rzecz. W robocie nie mam wyscigu szczorow, glupie stwierdzenie. Chodzi mi o takie rzeczy tez jak np ktos zrobie buga w kodzie to wiemy kto to zrobil. I tutaj znowu, @Aventus nikt nie linczuje tej osoby. Jak warto zwrocic uwage to zwracamy. Jezeli kazdy z tego bledu ma sie czegos nauczyc to tak robimy. A tak wychodzi, ze np autorem klasy PHP, jest front-end. Dla mnie to nie ma sensu. Ale ok.

Ustalcie rotację kto robi merge & squash, żeby statystyki się zgadzały.

Chodzi mi o takie rzeczy tez jak np ktos zrobie buga w kodzie to wiemy kto to zrobil.

Jak przeszło przez review to już Wasz wspólny błąd.

Ja bym głosował za "merge" - bardzo się przydaje informacja kto zmienił ostatnio daną linijkę albo kilka linii dookoła (w głównym repo - "main").
Jeśli "merge and squash" tę informację zamazuje to bym tego nie używał.
Piszę "jeśli" bo nie chce mi się sprawdzać.

@vpiotr Chociaz jedna osoba wie co pisze. A no tego sporo jest, developerzy wlasnie tez na to narzeka:

https://github.com/isaacs/github/issues/1368
https://github.com/isaacs/github/issues/1368

Mozliwe, ze nawet istnieje jakas opacja, zeby jednak zostawic oryginalnego autora:
http://git.661346.n2.nabble.com/Keep-original-author-with-git-merge-squash-td7625268.html
musze poczytac.

• merge bez dodatkowych opcji - unikać. Brak informacji o tym, kiedy nastąpiło wciągnięcie zmian potrafi czasami ugryźć w tyłek.
• merge --no-ff - jest ok, sam zazwyczaj tak postępuję.
• merge&rebase - pozwala na czystszą historię, ale czasami idzie się napocić przy konfliktach. Raczej unikam.
• merge&squash - sam wolę mieć "pełną" historię commitów w repo, choć rozumiem, że podejście "jeden commit = jeden ticket" ma sens. merge&squash moim zdaniem działa ok, gdy jest robione na zasadzie "autor squashuje i druga osoba merge'uje".

Merge bez squash i bez rebase. Nie psuć historii bez potrzeby. Nie robić mega commitów.