Wasze doświadczenia z Gitem prywatnie i zawodowo

2

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 :)

4

Korzystam z gita w domu i TFS w pracy.
W obu przypadkach korzystam z Trunk based development, branchy jak najmniej i jak najkrócej żyjące
Gita lubię za:

  • niski próg wejścia, wystartować z nowym repo można bardzo szybko
  • nadpisywanie/przepisywanie historii (squash, rebase)
  • github, w sensie jak przyjemnie się pracuje nad opensourcem
  • pracę offline

Gita nie lubię za:

  • integracja z IDE i narzędzia GUI są lata świetlne za tym co oferuje TFS
  • przeglądanie historii i robienie merge boli znacznie bardziej niż z TFS

Tak, TFS nie nadaje się kompletnie do pracy offline i pracy z branchami. Ale jeśli tego nie potrzebujemy, i mamy TFS postawiony na porządnym serwerze to cala integracja TFS z IDE i pozostałymi usługami które są oferowane w ramach tfs do prowadzenia projektu(zarządzanie work itemami, raporty, buildy) jest bardzo przyjemna. Jako system kontroli wersji tfs jest gorszy od gita, ale w połączeniu z pozostałymi usługami jest to znacznie wygodniejsze narzędzie do pracy niż git + jira + jakiś system buildowy.

Praca bez kontroli wersji nie ma sensu, nawet jeśli tą pracę wykonuje jedna osoba nad dokumentem worda.

5
mar-ek1 napisał(a):
  • Czy uważasz, że Git usprawnił Twoją/Waszą pracę?

Oczywiście. Po przeżyciach ze starszymi rozwiązaniami nie wyobrażam sobie powrotu do: svn, ClearCase, ... .

  • Jakie widzisz główne zalety korzystania z Gita?
  • działa offline
  • branch-e są zrobione jak należy
  • lekki
  • powszechnie używany
  • dobrze go poznałem (zwykle jestem lokalnym guru od git-a)
  • Czy wg Ciebie Git ma sens kiedy pracuje się samodzielnie?
  • jak najbardziej
  • 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?
  • każdy merge w git jest 10 razy przyjemniejszy niż w SVN
  • podczas każdego użycia produktu IBM do jakiego zostałem zmuszony okolicznościami
  • Jakie widzisz wady tego narzędzia (bo każde narzędzie ma wady, więc uważam, że warto je znać)
  • skomplikowane komendy, zwłaszcza checkout od wszystkiego. Używam +10 lat i nadal się muszę podpierać helpem/google. Analogicznie działający mercurial hg można opanować znacznie szybciej i nie trzeba ciągle wracać do helpa
  • Jeśli nie korzystasz z Gita prywatnie to dlaczego?
  • kod typu mały przykładzik na forum/SO, którego czas życia z mojej perspektywy to jeden dzień
  • Jeśli nie korzystacie z Gita w pracy to dlaczego?
  • bo korporacja, dla której się akurat pracuje, posiada jakąś stare alternatywne rozwiązanie od IBM-a i nie ma na co wyrzucać pieniędzy (na szczecie od lat już tego nie doświadczam).
  • Jaki styl pracy z Gitem wykorzystujesz? Git-flow? Coś innego? Wystarczy link jak to coś co już zostało opisane
  • brak u mnie preferencji, dostosowuje się do praktyk w danym projekcie.
  • Jeśli masz porównanie z innymi systemami kontroli wersji (SVN, TFS, Mercurial...) to który uważasz za lepszy? Dlaczego?
  • mercurial to to samo co git, ale kommendy ma bardziej logiczne i przyjazne. Osobiście wolałbym hg, ale pracuje z projektami w git. Brakuje mi szczególnie difftool z mercuriala, bo tam działa to o niebo lepiej (daje do porównania całe katalogi, a git iteruje plik po pliku)
  • SVN i pokrewne używałem wieki temu i pragnę o tym zapomnieć. Jedyna zaleta to mniejszy próg wejścia.
4

Czy uważasz, że Git usprawnił Twoją/Waszą pracę?

Tak.

Jakie widzisz główne zalety korzystania z Gita?

Mogę robić wiele lokalnych commitów bez potrzeby wrzucania tego na remote (np. praca z pociągu), mogę wygodnie robić branche i skakać między nimi a potem bezboleśnie mergować.

Czy wg Ciebie Git ma sens kiedy pracuje się samodzielnie?

Tak! Niektóre IDE maja wbudownane "local history" ale szukanie tam czegoś jest często trudne. Version control jest wygodniejsze bo masz własne "checkpointy".

Jakie widzisz wady tego narzędzia (bo każde narzędzie ma wady, więc uważam, że warto je znać)

Zbyt dużo sposobów na osiągniecie tego samego celu, co często powoduje problemy u nowych użytkowników. Fetch, merge, pull, rebase... Komunikaty błędów też często nie są jasne. Odkręcałem kiedyś akcje gdzie ktos zrobił rebase i chciał push na remote, ale oczywiście po rebase trzeba force, bo zmieniamy historie. Kolega nowy w gicie tego nie wiedział, a git napisał mu że stan repo się nie zgadza i że może powinien zrobić pull. No i on zrobił pull, tych samych zmian które już w kodzie miał, ale teraz aplikowanych ponownie na tym rebasowanym kodzie... :)

Jaki styl pracy z Gitem wykorzystujesz? Git-flow? Coś innego? Wystarczy link jak to coś co już zostało opisane

Branch per feature, potem merge do mastera po review. Tagi do oznaczenia jakichś dużych "releasów", ale generalnie continuous integration/deployment.

Jeśli masz porównanie z innymi systemami kontroli wersji (SVN, TFS, Mercurial...) to który uważasz za lepszy? Dlaczego?

Kiedyś korzystałem z SVNa no i jasnym jest że ma mniej możliwości. Branchowanie to 100% pain 0% fun (więc też trudno dziubać kilka ficzerów niezaleznie od siebie), nie można robić commitów offline, nie możesz łatwo synchronizować się ze zmianami w trunku na branchu, więc długi refaktoring kodu, który cały czas się zmienia, jest praktycznie niemożliwy.

2

Czy uważasz, że Git usprawnił Twoją/Waszą pracę?
Tak.

Jakie widzisz główne zalety korzystania z Gita?
Google it.

Czy wg Ciebie Git ma sens kiedy pracuje się samodzielnie?
Tak.

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?
Tak, używając w banku starego CVS bo nie mogłem z gita. Dodam, że wtedy korzystałem z gita lokalnie.
Plus z czasów kiedy git nie był tak popularny i SVN był głównym. Wiele merge konfliktów można byłoby uniknąć.

Jakie widzisz wady tego narzędzia (bo każde narzędzie ma wady, więc uważam, że warto je znać)
Nic wartego wspomnienia, bardziej kwestia jak ktoś korzysta.

Jaki styl pracy z Gitem wykorzystujesz? Git-flow? Coś innego? Wystarczy link jak to coś co już zostało opisane
Obecnie Git flow, choć preferuje trunk base development. Ten który stosowaliśmy w A przy N.

Jeśli masz porównanie z innymi systemami kontroli wersji (SVN, TFS, Mercurial...) to który uważasz za lepszy? Dlaczego?
Git.

7

Czy wg Ciebie Git ma sens kiedy pracuje się samodzielnie?

Zacząłem korzystać jakieś 3-4 korposeniory temu podczas pisania pracy magisterskiej, a więc mój pierwszy projekt z Gitem był samodzielny. Wtedy nie zagłębiałem się za bardzo w bardziej zaawansowane jego możliwości, chyba nawet nie używałem gałęzi za bardzo, ale poznałem wygodę daną przez możliwość częstego commitowania. Zdecydowanie pomaga nawet w pracy w pojedynkę.

Jakie widzisz główne zalety korzystania z Gita?

Git ma jak dla mnie takie główne zalety:

  1. Praca lokalna pozwala na używanie go jako jako trwałego undo/redo. Nawet bez serwera zdalnego, bez gałęzi, bez zaawansowanej edycji historii mamy coś, czego TfuFS czy SyfVN nie dają.
  2. Jest kompatybilny z mózgiem, który wpada na różne pomysły. Różne pomysły, to różne eksperymenty, czyli potrzeba napisania kodu w kilku wersjach, a potem porównania, które z nich wygląda najlepiej. W Gicie gałąź to błyskawiczna operacja w lokalnym repozytorium, w TfuFS czy SyfVN to wydarzenie na miarę odkrycia Indii przez Kolumba, na dodatek w przypadku TfuFSa dostępne tylko dla wybranych, bo wymagające specjalnych uprawnień na serwerze.
  3. Ponieważ gałęzie są lokalne, to ja decyduję, co widzą inni. Nie muszę upubliczniać swoich nieudanych eksperymentów czy zmagań z jakimiś problemami, mogę mieć wiele gałęzi lokalnych, w których coś kombinuję, a na origin wypchnąć tylko tą jedną z rozwiązaniem, które uważam za najlepsze.
  4. Posiada świetne GUI (przynajmniej jedno - GitExtensions, reszta się nie liczy), w którym od razu widać czytelnie wszystko, i które pozwala błyskawicznie porównywać zmiany w poszczególnych rewizjach, więc można łatwo i wygodnie znaleźć zmianę, która potencjalnie coś zepsuła albo pobrać sobie plik z innej gałęzi (bo np. tam już są zaimplementowane testy, które przydadzą się w obecnym toku implementacji). GUI w rodzaju Tortoise SVN czy obsługa kontroli wersji w Visual Studio są okropnie nieczytelne.

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?

Nie, bo nawet jak Gita oficjalnie nie było, to go sobie lokalnie instalowałem i używałem, więc mogłem pracować wygodnie. Potem jedynie musiałem używać wtyczki, aby zmergować moje zmiany do TfuFSa czy SyfVNa.
Oczywiście inni ludzie mieli problemy, bo np. nie mogli sobie swobodnie poeksperymentować, albo chcieli coś sprawdzić w innym branchu, ale architekt nie chciał go im zrobić. Sugerowałem użycie Gita, no ale nie każdy słuchał.

Jakie widzisz wady tego narzędzia (bo każde narzędzie ma wady, więc uważam, że warto je znać)

Jak dla mnie, to wad właściwie nie ma, ale mogę wymyślić takie trzy:

  1. Polecenia nie są zbyt intuicyjne, np. checkout służy zarówno do przełączania się między gałęziami jak i commitami wewnątrz jednej gałęzi. Albo zarówno merge jak i rebease mogą w pewnym sensie dawać ten sam efekt, ale robi się je w odwrotnych kierunkach. Gdy rozumie się Gita to jest to oczywiste, ale dla początkujących może nie być.
  2. Ciągle spotyka się betonowych architektów, którzy twierdzą, że jest za trudny do nauczenia i forsują jakieś swoje badziewie.
  3. Niektórzy myślą, że jak korzystają z konsoli, to są lepsi od innych (nawet jeśli na Windowsie konsoli zainstalować nie potrafią), więc mają kolejną okazję do flame warów.

Jaki styl pracy z Gitem wykorzystujesz? Git-flow? Coś innego? Wystarczy link jak to coś co już zostało opisane

Wykorzystuję wolność i elastyczność jaką daje Git, więc wpychanie się w wymogi o graniczenia jakiegoś enterprise procesu jak Git Flow uważam za jakiś absurd, nonsens i korporacyjny masochizm.
Do każdego taska tworzę sobie lokalny feature branch, do którego wrzucam zmiany, które uważam za dobre, a gdy potrzebuję poeksperymentować, czy coś porefaktoryzować, to od tej gałęzi odbijam sobie inne, a od nich jeszcze inne, jeśli mam taką potrzebę. Dobre zmiany squashuję do feature brancha, albo robię rebase - zależy od sytuacji i potrzeb. Jak skończę zadanie, to merguję mastera do swojego brancha, a w drugą stronę robię squasha, żeby cały task wszedł jako jeden commit. Wtedy nie ma problemu z rzekomą "nieczytelnością historii", na którą narzekają ludzie korzystający z Gita metodą Monte Carlo (czyli losowo klikając po ekranie).

Jeśli masz porównanie z innymi systemami kontroli wersji (SVN, TFS, Mercurial...) to który uważasz za lepszy? Dlaczego?

Te, które znam ułożyłbym w takiej kolejności:

  1. Git
  2. zip + FTP
  3. zip bez FTP
  4. nic
  5. SVN
  6. TFS
0

Dzięki wielkie za tak obszerne wypowiedzi :D
Będzie z czego rzeźbić potem gotową treść ;)

I oczywiście nadal temat otwarty bo wcześniej niż jutro się za opracowanie go nie zabiorę.

0

Ciekawa ankieta. Zważając na to, że jedyną poprawną odpowiedzą "Tak - w domu i w pracy", to ludzie co odpowiedzą inaczej powinni być banowani. A ten, kto w ogóle nie korzysta - rozstrzelany od razu.

4

Jakie widzisz główne zalety korzystania z Gita?

Historia zmian jest bardziej trwała niż persistent-history w Vimie. Dodatkowo można pracować nad paroma rzeczami równolegle.

Czy wg Ciebie Git ma sens kiedy pracuje się samodzielnie?

Tak. Usprawnia wersjownowanie, a nawet głupiego bloga można łatwiej prowadzić.

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?

Nawet jak używałem Gita to żałowałem, że nie robiłem tego dostatecznie często jak zmieniłem coś by działało, potem chciałem poprawić i przestawało działać. No a potem miałem problem by wrócić do działającego.

Jakie widzisz wady tego narzędzia (bo każde narzędzie ma wady, więc uważam, że warto je znać)

Jaki styl pracy z Gitem wykorzystujesz? Git-flow? Coś innego?

Głównie trunk-based, bo to IMHO jedyne rozwiązanie jakie ma sens. Git-flow w oryginalnej postaci ssie

Jeśli masz porównanie z innymi systemami kontroli wersji (SVN, TFS, Mercurial...) to który uważasz za lepszy? Dlaczego?

Ogólnie lubię Gita, ale cały czas się zbieram by przetestować Pijul by zobaczyć jak będzie się sprawowało diff-based VCS w porównaniu z file-based.

4

Dużo lat się męczyłem z CVS, potem SVN, więc nie umiem za bardzo narzekać na GITa. Jest wyraźnie lepiej, i w sumie od momentu jak usłyszałem koncepcję to pytałem się czemu wcześniej nikt na to nie wpadł (de fakto wpadł, tylko o tym nie wiedziałem).
Chociaż jak wszystkie toole, GIT nie jest odporny na mnie i raz na jakiś czas zdarza mi się konflikt z samym sobą - czyli merge konflikt w projekcie, gdzie jestem jedynym commiterem i pracuje na jednym laptopie ¯\_(ツ)_/¯ . Na szczęście , w projektach z ludźmi dużo rzadziej sie to zdarza i do tego problem akurat w GIT łatwo rozwiązać (taki sam problem w SVN skutkował czasem zakładaniem projektu od nowa...).

3

uzywam gita od ok 10 lat

  • Czy uważasz, że Git usprawnił Twoją/Waszą pracę?

zdecydowanie

  • Jakie widzisz główne zalety korzystania z Gita?

lekkie branche, latwosc merge/rebase, cala historia lokalnie i koncept staging przed commitem

  • Czy wg Ciebie Git ma sens kiedy pracuje się samodzielnie?

jasne, nawet przy projektach skladajacych sie z jednego pliku jest to wygodne rozwiazanie chocby ze wzgledu na historie

  • 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?

wiele razy moglabym uniknac problemu gdybym zawsze trzymala w gicie takie rzeczy jak configi czy manualnie zarzadzane slowniki z danymi

  • Jakie widzisz wady tego narzędzia (bo każde narzędzie ma wady, więc uważam, że warto je znać)

ciezko mi wymienic cos czego nie udalo mi sie rozwiazac w zadowalajacy sposob, moze prog wejscia przez co demokratycznie moze to nie przejsc w niektorych ogranizacjach

  • Jeśli nie korzystasz z Gita prywatnie to dlaczego?

nie wersjonuje automatycznie generowanych zrodel/konfiguracji/danych/binarek i rzeczy do ktorych na pewno nie wroce

  • Jeśli nie korzystacie z Gita w pracy to dlaczego?

ja zawsze korzystam przynajmniej lokalnie, jak ktos nie korzysta to zwykle dlatego ze jest betonem ;)

  • Jaki styl pracy z Gitem wykorzystujesz? Git-flow? Coś innego? Wystarczy link jak to coś co już zostało opisane

tylko trunk based

  • Jeśli masz porównanie z innymi systemami kontroli wersji (SVN, TFS, Mercurial...) to który uważasz za lepszy? Dlaczego?

mercuriala uzywalam przed gitem i byl calkiem ok, ale git jest popularniejszy i ma wieksze mozliwosci, do systemow typu svn nie ma co porownywac...

1
  • Czy uważasz, że Git usprawnił Twoją/Waszą pracę?

Git był zarazem pierwszym systemem kontroli wersji, którego używałem, więc moja odpowiedź może być bardziej o kontroli wersji, niż samym gicie - ale tak, zdecydowanie usprawnił moją pracę. Obecnie ciężko mi wyobrazić sobie pracę bez niego, stosuję go niemal wszędzie - nie tylko do kodu, ale także do notatek czy inszej maści tekstu.

  • Jakie widzisz główne zalety korzystania z Gita?
  1. Gałęzie - mogę bez problemu pracować sobie nad kilkoma rzeczami "jednocześnie". Pogrzebię coś w jednym temacie, git checkout, mogę robić coś innego w ramach projektu i w żaden sposób się to ze sobą nie gryzie.
  2. Historia - zarówno w sensie po prostu czytania commit messages w ramach git log, jak i w sensie wyciągania rzeczy z historii - np. czasami jest potrzeba przywrócić jakiś usunięty fragment kodu, albo po prostu spojrzeć, jak coś wyglądało jakiś-tam czas temu.
  3. Śledzenie zmian - jeżeli się zagubię w tym, co robię, to git status w tandemie z git diff od razu mi wszystko powiedzą.
  4. Powiązane z poprzednim punktem - jak coś kosmicznie skaszanię, to git reset --hard i kod jest w znanym, sensownym stanie.
  5. Rebase, chery-pick - możliwość pół-automatycznego edytowania historii czy przenoszenia kodu między gałęziami.
  6. O ile ogarnięte są inne tematy typu "każdy ma środowisko developerskie" oraz polityka gałęzi, to używanie gita w zespole znacznie ułatwia pracę i nie wchodzenie sobie nawzajem w drogę.
  • Czy wg Ciebie Git ma sens kiedy pracuje się samodzielnie?

Zdecydowanie, patrz cztery pierwsze punkty w odpowiedzi powyżej.

  • 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?
  1. Dawno temu, gdy jeszcze nie stosowałem kontroli wersji w ogóle i zgubiłem kod do projektu (tzn. zgubiłem najnowszą wersję, miałem jakieś backupy).
  2. Parę razy gdy miałem nowy i stary kod, ale bez historii commitów i potrzebowałem wyizolować jakieś zmiany.
  • Jakie widzisz wady tego narzędzia (bo każde narzędzie ma wady, więc uważam, że warto je znać)
  1. Git nie jest szczególnie intuicyjny na start i poznanie go w dobrym stopniu zajmuje trochę czasu.
  2. Interfejs CLI jest trochę niespójny.
  • Jaki styl pracy z Gitem wykorzystujesz? Git-flow? Coś innego? Wystarczy link jak to coś co już zostało opisane

Pracowałem w git-flow, sam raczej wolę trunk-based development.

0

_

Czy uważasz, że Git usprawnił Twoją/Waszą pracę?

Tak, ale nie tak bardzo jak Github.

Jakie widzisz główne zalety korzystania z Gita?

Github. Tooling.

Czy wg Ciebie Git ma sens kiedy pracuje się samodzielnie?

Tak.

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?

Nie kojarzę.

Jakie widzisz wady tego narzędzia (bo każde narzędzie ma wady, więc uważam, że warto je znać)

Według mnie niektóre operacje niepotrzebnie wymagają robienia jakichś "workaroundów" czy naklepania się 5 komend. coś w ten deseń.

Jeśli nie korzystasz z Gita prywatnie to dlaczego?

Zbyt krótki kod

Jeśli masz porównanie z innymi systemami kontroli wersji (SVN, TFS, Mercurial...) to który uważasz za lepszy? Dlaczego?

Git ma lepszy tooling niż TFS oraz wydaje się być znacznie szybszy (@neves napisał że wręcz przeciwnie :D ciekawie, ale chyba wiem z czego może to wynikać :P)

2

Jeszcze raz dzięki wszystkim za odpowiedzi :) właśnie kończę montaż video więc na pewno się tutaj albo na mikroblogu niedługo pojawi.
Tylko wymyśliłem sobie, że fajnie będzie tam jakieś miłe grafiki dodać więc jeszcze będę u koleżanki zamawiał takowe co trochę wydłuży proces :D

2

Materiał się pojawił i napisałem o nim na mikroblogu :)

Nie byłem pewien czy edycja posta poinformowała by osoby śledzące wątek, dlatego dodaję post pod postem.

2

Piszę teraz książkę i używam do tego kontroli wersji. Git okazał się strzałem w 10.

1 użytkowników online, w tym zalogowanych: 0, gości: 1