Jedna rzecz, którą wprowadziły systemy rozproszonych repozytoriów w stylu Git czy Mercurial to powszechne niemal przepisywanie historii.
Pomysły robienia squasha przed wypchnięciem zmian do remote, albo nawet przepisywanie historii przez --force.
Bardzo mnie to denerwuje.
W jednym projekcie gdy przeszedłem do innego nowo przybyły dev przepisał historie tak, że praktycznie cały początek projektu zniknął i już go nie było....
Jeszcze Ok jestem z tym jak ktoś przepisuje swoją historię, w sensie nigdy kodu nie wypycha i sobie lokalną historię przepisuje. Do momentu gdy commit message są w miarę opisowe to jest Ok.
Ale jak ktoś przepisuje historię czegoś co zostało już wypchnięte to mi się nie podoba i jest źródłem problemów. Bo ktoś mógł zrobić clone czy pull i może mieć lokalnie taką wersję, która zostanie skasowana.
Kasowanie branchy to już w ogóle zbrodnia, bo nagle dotarcie do tego czemu coś jest w kodzie tak, a nie inaczej jest praktycznie awykonalne.
Do tego jak próbuję odzyskać info o swoich zmianach sprzed kilku lat to bez magii polegającej na zaglądaniu do niby skasowanych commitów się nie obędzie....
Pomysły robienia squasha przed wypchnięciem zmian do remote, albo nawet przepisywanie historii przez --force.
Bardzo mnie to denerwuje.
W jednym projekcie gdy przeszedłem do innego nowo przybyły dev przepisał historie tak, że praktycznie cały początek projektu zniknął i już go nie było....
Jeszcze Ok jestem z tym jak ktoś przepisuje swoją historię, w sensie nigdy kodu nie wypycha i sobie lokalną historię przepisuje. Do momentu gdy commit message są w miarę opisowe to jest Ok.
Ale jak ktoś przepisuje historię czegoś co zostało już wypchnięte to mi się nie podoba i jest źródłem problemów. Bo ktoś mógł zrobić clone czy pull i może mieć lokalnie taką wersję, która zostanie skasowana.
Kasowanie branchy to już w ogóle zbrodnia, bo nagle dotarcie do tego czemu coś jest w kodzie tak, a nie inaczej jest praktycznie awykonalne.
Do tego jak próbuję odzyskać info o swoich zmianach sprzed kilku lat to bez magii polegającej na zaglądaniu do niby skasowanych commitów się nie obędzie....
posted from Bloggeroid
Podobne postybeta
O tym czemu branche są złe...
Dziwne linki w iGoogle ;-)
Historia czy Histeria? ;-)
[*] najbardziej pusty imotek
Interakcje
Czyli jak zrobisz git branch -a, to ma być gigantyczna litania? Coś mi tu nie gra. Ile żyją Twoje branche, że nie chcesz ich kasować?
OdpowiedzUsuńZacznijmy od tego, że ja jestem przeciwnikiem branchy, branche są wg mnie złym pomysłem. Zawsze jak jest o tym dyskusja to słyszę, że developerzy czują się dzięki nim "bezpieczniej" bo ktoś im kodu nie zmieni. Ale robiłem symulacje i widziałem w prawdziwym życiu, że to czy ktoś Ci kod zmieni czy nie jest funkcją tego jak często się integrujesz z master/trunk/main. Im częściej to robisz tym mniejsze ryzyko konfliktu. A branche w naturalny sposób prowadzą do tego, że ludzie się rzadko integrują. Kod potrafi tydzień czy dłużej żyć na branchu i rozjeżdżać się z tym co jest na innych branchach.
UsuńNie chcę kasowania branchy i przepisywania historii bo tracę kontekst tego w jakim otoczeniu była dana zmiana. Dostaję zmianę 300 plików czy nawet tylko 30 i szukaj teraz wiatru w polu. Bez przepisywania historii i bez branchy bym widział zwykle, że dana zmiana była z innym konkretnym plikiem, i opis by mi coś mógł dać.
Treść commit message'y to jest kolejna sprawa. Ludzie używają commit'ów jako "checkpointów" i w razie czego wracają, a opisy mają w stylu "refactor 2" albo "cleanup" i później jak robią squash to dają opis dotyczący tego co pamiętają z ostatniego commita i "całokształtu", a nie konkrente informacje, czemu np. zmienili nazwę klasy, albo że połączyli 2 w jedną, albo rozbili jedną na 3.
Ten komentarz został usunięty przez autora.
UsuńHmm… złym. Daja Ci komfort robienia commit i push nawet w stanie niestabilnym. Co ktoś z tym później zrobi… dawno temu Szczepan albo Igor, ze wskazaniem bardziej na Szczepana, zaszczepili mi filozofię "you merge, you lose".
Usuń