Cześć,
Planuję przygotować materiał na temat korzystania z Gita zarówno w pracy jak również w projektach prywatnych, robionych po godzinach - wady, zalety, różne podejścia. Ale żeby nie opierać go tylko na swoich doświadczeniach i przypuszczeniach to mam małą ankietę :) Jak to też zwykle w życiu bywa - teoria teorią, ale doświadczenia z frontu mogą być zgoła inne.
Poza odpowiedzią na pytanie czy używacie Gita będę bardzo wdzięczny za podzielenie się wrażeniami w tym temacie. Przykładowe pytania:
- Czy uważasz, że Git usprawnił Twoją/Waszą pracę?
- Jakie widzisz główne zalety korzystania z Gita?
- Czy wg Ciebie Git ma sens kiedy pracuje się samodzielnie?
- Czy miałeś/miałaś moment (przykład dodatkowo punktowany ;) ) kiedy żałowałeś/żałowałaś, że nie było Gita bo można by uniknąć problemu?
- Jakie widzisz wady tego narzędzia (bo każde narzędzie ma wady, więc uważam, że warto je znać)
- Jeśli nie korzystasz z Gita prywatnie to dlaczego?
- Jeśli nie korzystacie z Gita w pracy to dlaczego?
- Jaki styl pracy z Gitem wykorzystujesz? Git-flow? Coś innego? Wystarczy link jak to coś co już zostało opisane
- Jeśli masz porównanie z innymi systemami kontroli wersji (SVN, TFS, Mercurial...) to który uważasz za lepszy? Dlaczego?
Żeby zacząć:
Używam Gita prywatnie i w pracy. W domu zacząłem go używać później, najpierw poznałem to narzędzie w projekcie, do którego dołączyłem. W prywatnych projektach największą zaletą jest to, że wprowadzając szalone zmiany i refactoring nie ma problemu, że poszedłem za daleko i teraz coś co działało przestało działać i nie ma jak tego odkręcić. To daje mi dużo większą pewność w testowaniu jakichś nowości, których się uczę.
W pracy dużą zaletą jest fakt, że dzięki branchom nie wchodzimy sobie w drogę i można w miarę niezależnie pracować nad swoim fragmentem. Do tego robienie code review jest proste, przez to, że dostaję diff zmian. Poza tym nieraz przydawała się historia zmian aby prześledzić co działo się wcześniej z jakimś modułem. I tak jak w projektach prywatnych tak i zawodowo - w razie zbyt szalonych innowacji w kodzie zawsze można ze spuszczoną głową wrócić do tego co działało (i najwyżej zachować eksperymenty w jakimś lokalnym branchu, na lepsze czasy).
Miałem też epizody z TFSem i SVNem i oba te narzędzia powodują, że człowiek jak najmniej chce robić commity i odkłada się moment podzielenia się zmianami do samego końca. Do tego Git ma tą przewagę, że nawet jak zerwie neta albo serwer nie działa to nadal możemy bez problemu pracować - w TFSie zwykle to oznaczało przerwę w pracy bo Visual Studio regularnie przypominał, że jest coś nie tak.
Pracowałem zarówno z robieniem rebase i pushowaniem do mastera tylko zmian typu fast-forward, ale też eksperymentowaliśmy z git-flow, które wg mnie ma zbyt duży narzut i zbyt wiele elementów, o których trzeba pamiętać.
Z wad to zauważyłem, że bardzo łatwo doprowadzić do bardzo dziwnej historii zmian, którą trudno przeglądać. Wymaga to ciągłego dbania o trzymanie standardu, który wypracowaliśmy. A o ile w przypadku kodu możemy chociażby jakąś statyczną analizą zapewnić minimum standardu tak w Gicie jakiś jeden pożar albo sytuacja, której nie przewidzieliśmy albo nie zauważyliśmy i historia się może posypać na jakiś czas i nagle mamy rozjazd w stylu pracy. Więc przy mniej doświadczonym zespole można szybko dojść do poplątania z pomieszaniem.
PS: Jak materiał (na 99% video) będzie gotowy to podrzucę tutaj :)