SVN rzeczywiście jest prostszy, ale bez przesady. To tak jakby porównywać rower z samochodem - w teorii oba służą do tego samego, ale jak się opanuje samochód, to się nim porusza znacznie szybciej i wygodniej.
Jak ktoś mi mówi, że wadą DVCS jest lokalne repo i to, że baranche są lekkie to automatycznie wiem, że taka osoba nie rozumie idei, która za tym stoi. Co więcej, im większy projekt tym większy jest sens zastosowania DVCS. Wyobraźmy sobie, że gdzieś pojawia się nam w repo błąd (całkiem prawdopodobne) i jest on niezauważony przez powiedzmy 2 lata. Wypływa on na wierzch i nagle panika, bo nie wiadomo, które wersje są narażone. W Gicie znajduje się bardzo przydatna komenda git bisect
, która tak na prawdę może całą robotę odwalić za nas automatycznie. W SVNie? Mamy do tego skrypt Perla (yay, wszyscy kochamy Perla), ale przeskakiwanie między kolejnymi rewizjami zajmie wieki (zwłaszcza jeśli team jest cały mobilny i nie ma dostępu do serwera gdzie składuje się kod).
Mówisz, że szanujesz swój czas, a nie chcesz się nauczyć narzędzia, które pozwoli Ci go w znacznym stopniu zaoszczędzić. No cóż, niektórzy ludzie nie potrafią planować długoterminowo.
Jak masz organizację ~150-osobową pracującą nad 1 repo w stylu gwiaździstym to ja się nie dziwię, że jest burdel (przy SVNie był by pewnie jeszcze większy, bo praca niektórych by polegała na czekaniu, aż będzie mógł zrobić commita). Parę rzeczy - wprowadźcie strukturę drzewiastą pracy (15 osobowe zespoły z wyznaczonym leadem), podzielcie repo na mniejsze projekty oraz stwórzcie style guide (ktoś projekt musi prowadzić, więc niech ta osoba powie, że robimy tak i tak i koniec, pull-requesty nie będą przyjmowane od osób, które się nie stosują). Znacznie łatwiej będzie.
Powiem tak, gdyby przy takiej organizacji zastosować SVNa, to serwer eksplodował by w ciągu jednego dnia lub powstał taki chaos, że przez następne 3 lata byście się z niego wygrzebywali. Jedna z ideii używania Gita jest taka (http://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows):
- wszyscy mają to samo w masterze, do którego mogą commitować tylko project leadzi (albo nawet oni nie mogą commitować bezpośrednio, a tylko narzędzie do code review)
- każdy nowy feature powstaje w nowej (lokalnej) gałęzi wymergowanej z mastera - dzięki temu (o ile są dobre testy) wiadomo, że cokolwiek chciałem dodać/poprawić/zrefaktoryzować nie spieprzyło tego co już działa
- commity wykonuje się gęsto i często (po parę linijek) bo można i dzięki temu mamy coś w stylu "persistent undo" (jak ktoś używa Vima to za pewne ma to i bez tego)
- kiedy uznamy, że feature jest ukończony robimy
git rebase -i --autosquash
by z wuchty małych, jednolinijkowych, commitów zrobić bardziej sensowne grupy, które są ładnie opisane (no i pozbyć się wszystkich fixup!
i squash!
, polecam sprawdzić git help rebase
i git help commit
)
- CI robi testy by mieć pewność, że nic nie spapraliśmy
- ktoś robi review
- team lead robi signed merge do repo teamu
- pod koniec sprintu/ukończeniu głównego taska jest robiony pull-request do głównego repo (to się może dziać automatycznie)
- znów CI
- znów review
-
signed merge do mastera
Przy takim toku pracy masz pewność, że nikt niczego nie spieprzy i kod w masterze powinien działać.
Więc IMHO dalej uważam, że skoro twierdzisz, że Git nic nie wnosi, poza zwiększoną złożonością narzędzia, to po prostu go nie znasz. By wypowiadać się nt. użyteczności narzędzi warto je wpierw poznać :)