[CamelCase]

Mirki, odkryłem ostatnio fantastyczny workflow dla małych i średnich projektów. Łączy on w sobie przejrzyste i piękne główne gałęzie ze świętością historii gałęzi roboczych. Wydaje mi się on praktycznie pozbawiony wad i zastanawiam się dlaczego wszyscy tak nie robią.

Główne gałęzie: master, develop, feature branche do każdego zadania

1. Na masterze jest aktualna wersja stabilna, na developie pracujemy.
2. Załóżmy, że dostałem zadanie numer 33, które polega na implementacji magicznego sortowania.
3a. git checkout develop
3b. git pull
3c. git checkout -b camel-33
4. Zaczynam implementować magiczne sortowanie na gałęzi camel-33
5. W tym czasie kolega zmergeował do developa magiczny swap. Jest stabilny i mi się przyda.
6. git rebase develop
7. Kończę implementować magiczne sortowanie. Po drodze zrobiłem mnóstwo gówno-commitów typu "Fixed shitty comments". Na developa też trafiły inne rzeczy, przez co jestem w tyle.
8a. git checkout develop
8b. git pull
8c. git checkout camel-33
8d. git rebase develop
8e. git checkout develop
8f. git merge --squash camel-33
8g. git add .
8h. git commit
8i. git push

Flow ten ma następujące zalety:
1. develop ma piękną liniową historię, gdzie commity i taski są 1:1 i każdy commit można powiązać z konkretnym feature-branchem. Ordung jak w Wermachcie.
2. Wszystkie commity zostają na camel-33 dokładnie tak jak były implementowane. Możemy zostawić tam także te gówniane, historia jest święta. Ogólnie gałąź zadania jest dla programisty, w razie gdyby musiał coś poprawić, zrobić revert itp.
3. Nie trzeba się specjalnie przykładać do opisów i spójności commitów w trakcie pracy, bo nigdy nie trafią one na developa.
4. Wszystkie konflikty są rozwiązywane podczas rebase z punktu 8d commit po commicie, co jest znacznie łatwiejsze niż rozwiązanie wszystkich naraz.
5. Każdy merge to fast-forward.
6. Rebase do developa możemy zrobić w dowolnym momencie i tyle razy ile chcemy, przez co nasz feature-branch nigdy nie jest przestarzały.
7. Różne feature-branche nie mieszają się ze sobą.
8. Nasz flow nie wygląda jak guitar-hero. ( ͡° ͜ʖ ͡°)

Co o tym myślicie? Jeszcze nigdy nie widziałem dokładnie takiego opisu.
#git #programowanie

[s.....r]

@CamelCase: Thx, sobie zapisze i obczaje w domu #pracbaza uzywa #svn :/

[pietryna123]

@CamelCase: Popsuję ci dzień. Ericsson tak robi przy czym nikt się nie pieprzy z masterem który jest pusty. Develop jest maintrackiem, na nim chodzi cały CI itp.

Przy czym punkt 8 wygląda raczej tak
git remote update
git rebase -i origin/develop - w tym kroku jest sqush
git add .
git commit -s
- > gerrit i merge jest robiony automatycznie po review

squash w ogóle ma wadę bo znikają ci

[L.....F]

@CamelCase:
1. często zbędne jest trzymanie master i develop, wystarczy master.
2. masz jeden komit na task? #!$%@?. Komity mają być niewielkie. powodzenia w przypadku git bisect. "ta rzecz została popsuta w tym komicie na 100000 linii"
3. można trzymać porządek w komitach na ficzer branczui równocześnie móc sobie dowolnie czekałtować, revertować, itp
4. po merge albo tracisz całą historię dev-komitów, albo masz miljon branczy ficzer, które na nic się nie

[CamelCase]

@LOLWTF:
Ad 1. Może. Przyzwyczaiłem się już, że pracuję z developem. Ten master jest gdzieś tam z tyłu, nie wiem po co, ale widocznie komuś jest potrzebny.

Ad 2. Robisz bisect na developie i wiesz, który taks #!$%@?ł sprawę. Robisz checkaut na odpowiadający mu feature-brach, robisz bisect i wiesz już który commit jest wadliwy. Niewiele więcej roboty tak naprawdę.

Ad 3. Teoretycznie można, a jak jest w praktyce to każdy widzi

[L.....F]

to i tak w zespole znajdzie się ktoś z bardziej nonszalanckim podejściem do commitów. I w sumie ma do tego prawo - jego branch, jego sprawa.

@CamelCase: No nie do końca. Tak samo, jak zespół trzyma się code guide, tak samo powinien się trzymać standardów związanych z vcs.

Poza tym skupianie się na repo odciąga uwagę od kodu i zadania.

Jest odwrotnie. Git pomaga utrzymać systematyczność w pracy i rozdziela pracę

[piotrb]

Ericsson tak robi przy czym nikt się nie pieprzy z masterem który jest pusty. Develop jest maintrackiem, na nim chodzi cały CI itp.

@pietryna123:
@CamelCase:
No właśnie od samego początku gryzło mnie po co ta komplikacja z podziałem.

[CamelCase]

@piotrb: Wiesz, w dużych projektach z release'ami i wersjonowaniem to ma jakieś tam zastosowanie. Poczytaj sobie o GitFlow.

[pietryna123]

@CamelCase: Ja się odniosłem na przykładzie projektu gdzie pracuje nad nim ze 300 osób, są różne moduły, różne poziomy CI itp.

[piotrb]

Wiesz, w dużych projektach z release'ami i wersjonowaniem to ma jakieś tam zastosowanie.

@CamelCase:
Kto to napisał?
"odkryłem ostatnio fantastyczny workflow dla małych i średnich projektów"

Workflow musi być maksymalnie prosty, bo przychodzi brzytwa Ockhama ....

[CamelCase]

@piotrb: Po przemyśleniu sprawy przyznaję Ci rację w tej kwestii.

[i.....k]

@CamelCase: Robimy to samo pomijając branch develop, feature branche po PR i code review idą na mastera i automatycznie na produkcję.