[GratisLPG]

#heheszki #humorobrazkowy #humorinformatykow #programowanie

[e-stark]

@GratisLPG: robi się raz a dobrze a nie commituje po kawałku

[eloar]

@GratisLPG: zaglądasz a tam commity zmieniające copyright w README.md albo master/slave na primary/secondary. Takich specjalistów nam najbardziej potrzeba.

[m4kb0l]

robi się raz a dobrze a nie commituje po kawałku

@e-stark: właśnie nie. Commituje się małe zmiany ale przynoszące wartość

[Kresse]

@e-stark: właśnie nie. Commituje się małe zmiany ale przynoszące wartość

@m4kb0l: *Ja patrzący na 400 zmienionych plików po małych refaktoryzacjach, które zrobiłem przy okazji dodawania nowego przycisku*

[Rst00]

@m4kb0l: taa, a później śmietnik w historii gita bo ktoś podczas robienia jednego feature'a commitował co chwilę i jest 20 lub więcej commitów nakichane xD Później super się przegląda zmiany konkretnego pliku jak ktoś 10 razy go zmieniał w ramach jednego feature'a xD Im bardziej płaska historia w gitcie tym lepiej i o ile jeszcze rozumiem że ktoś podczas developmentu sobie commituje co chwilę to wypychanie tego na origin to "xD".

[Krolik]

@Rst00: Nie nasz racji. Im bardziej szczegółowa historia w gicie tym lepiej. Przede wszystkim im bardziej szczegółowe commity tym łatwiej znaleźć błąd za pomocą bisect. Bisect wskaże Ci commit który wprowadził błąd. Dużo łatwiej zrozumieć skąd się błąd wziął patrząc na 10 zmienionych linii niż na 10 tys linii (tak, widzę czasami takich łosi #!$%@?ących 10k zmian). Po drugie dużo łatwiej robić review małych zmian.

Squash należy robić tylko w sytuacji

[Rst00]

@Krolik: ale chwila, chwila. Kto mówi o 10 tys. linii w ramach jednego feature'a czy naprawy buga? Standardowy feature to max 15-30 plików per PR. Większe już sugerują że to powinno być dawno rozbite na mniejsze części ale jak w ramach tych 15 zmienionych plików (to może być zarówno 15 linijek jak i 200 linijek) to kilkanaście commitów wprowadza tylko śmietnik. Najczęściej szuka się w historii gita jakichś informacji co, kto

[Krolik]

@Rst00: Nie ma absolutnie nic złego w commitach które zmieniają jedna linijkę, jeżeli ta zmiana jest samodzielna, tzn. projekt przechodzi testy po zmianie. Śmietnik robią commity, w których masz połączone kilka niezwiązanych lub słabo ze sobą związanych zmian. Przykładowo, implementujesz jakiś ficzer i nagle widzisz, że trzeba zrobić refaktoring, to refaktoring powinieneś robić osobnym commitem a właściwy ficzer osobnym. Scalanie commitow tylko po to aby było ich mniej to jakiś głupi

[Rst00]

@Krolik: no ale znowu wprowadzasz niepotrzebną komplikację. Jak masz do zrobienia feature "X" to robisz feature "X". Jak widzisz że potrzebny jest refactor to zakładasz nowy task, robisz osobny commit tylko dla tych zmian i to jest ok. Nikt nie powiedział że trzeba wszystkie niezwiązane ze sobą commity scalać. Mi chodzi o commity w ramach jednego feature'a np. robisz zmianę w pliku "A", jest jak chcesz więc robisz commit, w trakcie

[Krolik]

@Rst00: Po cholere zakładać osobnego taska jak wiem co mam zrobić? Teraz to już proponujesz serio cargo-cult. A każdy ficzer może się składać z mniejszych zmian wynikajacych ze struktury projektu. Nie każda z tych małych zmian jednak w ogóle jest widoczna dla użytkownika końcowego.

[Rst00]

@Krolik: ale co ma jedno wspólne z drugim? Programując zostawia się pewny dług technologiczny zawsze i po czasie może przyjść konieczność przerobienia danego rozwiązania co nie oznacza że nie powinno się zakładać do tego taska. Jak masz taska z featurem a po drodze wychodzi konieczność takich właśnie przeróbek (gruby refactor z całkowitą zmianą podejścia) to dlaczego miałbyś nie zakładać nowego taska? Później łatwiej będzie wyśledzić co/dlaczego/po co. To że zmiana jest

[przemek_95]

@Rst00: Polecam zapoznać się z artykułem
https://www.aleksandrhovhannisyan.com/blog/atomic-git-commits/

[Krolik]

@Rst00: no to właśnie od tego masz osobne commity aby poboczne rzeczy do nich pakować. Taski są od zarządzania projektem, to coś zupełnie innego i jest niezależne od historii Gita. Commity powinny być najmniejsze jak to możliwe, z zachowaniem poprawności projektu.

[Krolik]

@Rst00: > Programując zostawia się pewny dług technologiczny zawsze

Może Ty. Pisz za siebie.

[Rst00]

Może Ty. Pisz za siebie.

@Krolik tak, tak. Twój kod nie zostawia żadnego długu technologicznego i jest czysty jak łza xD Weź nie opowiadaj takich głupot bo ktoś mniej doświadczony to przeczyta i w to uwierzy.

no to właśnie od tego masz osobne commity aby poboczne rzeczy do nich pakować.

@Krolik Ja nie wiem czy ja piszę po chińsku czy Ty czegoś nie rozumiesz. Szkoda mi jednak czasu na dyskusje bo widać

[Krolik]

@Rst00: to w takim razie nie rozumiesz czym jest dług technologiczny. Radzę doczytać definicję. Dług technologiczny to nie jest "za 3 miesiące trzeba będzie ten kod zmienić jeśli się zmienią wymagania albo kiedy będziemy robić nowy ficzer". Dług technologiczny to nie jest również "robimy byle jak, ale kto teraz robi dobrze" ani "kod wymaga utrzymania".

A co do commitów to problem polega na tym że Ty się odwołujesz do jakiegoś subiektywnego

[Kresse]

@Krolik: W zasadzie to oboje macie racje i imho w praktyce roznica jest niewielka. Pojedyncze i spojne commity sa super, ale szansa na to, ze kazdy w zespole bedzie zachowywal taka dyscypline przy commitowaniu jest bliska zera. Z drugiej strony podczas rozwiazywania problemow taki poziom detalu bardzo rzadko jest potrzebny - najczesciej interesuje nas biznesowa przyczyna danej zmiany i to kiedy zostala ona wprowadzona. Jesli dostaje null pointery, bo ktos zacommitowal

[Krolik]

@Kresse: No jeśli biznesowych przyczyn nikt nie pisze w komitach, to macie jakiś problem z kulturą. Opis w komicie nie służy do tego aby opisywać co się zmieniło (bo to git i tak rejestruje automatycznie) ale właśnie po co lub dlaczego się zmieniło. Poza tym dobrym zwyczajem jest też umieszczać id taska w komicie. W ten sposób wyciagniecie wszystkich zmian dotyczących danego ficzera jest trywialne.

A tak na marginesie, co do

[Kresse]

@Krolik: ID taska to must have i to w zupelnosci wystarczalo w chyba kazdym moim projekcie do tej pory. Imho przepisywanie ticketa do commitow nie ma sensu, bo wyszukanie taska po ID w Jirze czy innym narzedziu jest rowniez trywialne i nie wymaga dodatkowej pracy. Zreszta poleganie na opisach commitow w tak duzym stopniu wskazuje raczej, ze cos jest mocno nie tak z wiedza o projekcie, ktorej miejsce jest w dokumentacji,

[Krolik]

@Kresse: samo id taska nie wystarczy, bo w tasku po pierwsze nie zawsze masz komplet informacji o tym jakie rozwiązanie zostało podjęte, po drugie nie masz gwarancji że system do tasków będzie na zawsze ten sam. No i wyszukiwanie w takiej jirze jest koszmarnie powolne. Lepiej mieć historię, która jest samodzielnie wystarczająca. Taski są tylko dodatkowa informacja.

A dokumentacja oczywiście tak jak najbardziej musi być i jest bardzo ważna. Ale w