Git jest git jak mawia Spartakus Maciej jednak nie każdemu dane jest dostąpić do tego świętego Grala bo sporo firm używa np svn-a. Sam jestem w takiej sytuacji, że wewnątrz firmy obowiązuje jedyny słuszny svn i nikt nie ma zamiaru zmieniać tego dla jednego marudzącego kolesia. W takiej sytuacji trzeba sobie radzić samemu. Git ma wbudowanego klienta svn-a i nic ale to zupełnie nic nie stoi na przeszkodzie, aby korzystać z niego jako klienta svn.
Do wykonania git-> svn potrzebujemy instalkę gita i tyle.
Uruchamiamy konsolę i odpalamy polecenie
git svn clone https://adres.do.naszego/super/repozytorium/svnowego .
to spowoduje, że cały projekt zostanie zassany do gitowego repozytorium. Ot i cała filozofia. Od tej pory można pracować jak człowiek i przestać marudzić na svn-a (koniec wymówek).
Co do szczegółów. Powyższa komenda pobiera CAŁE repozytorium więc mamy dostępną cała historię (to jest plus), jednak operacja chwilę trwa (minus) – na szczęście jest to jednorazowa operacja (plus).
Ważna inforamcja. Na końcu komenty (po spacji) jest kropa. Ta kropka nie jest przypadkowo. Dodanie jej ściągnie nam tylko trunk-a i nie stworzy podkatalogu trunk. Więc w zależności czy chcesz mieć trunk-a czy nie to dodaj lub usuń kropkę na końcu.
Jest jeszcze jedna metoda, trochę szybsza.
git svn init https://adres.do.naszego/super/repozytorium/svnowego
to stworzy nam puste repozytorium bez pobierania źródeł. To co nam teraz pozostaje to pobrać źródła np. bez historii
git svn fetch –r HEAD
lub bez historii i bez tagów (jeśli twój Build Serwer zakłada tagi przy każdym buildzie)
git svn fetch –r HEAD –ignore-paths=”^tags”
zresztą –ignore-paths=”^tags” można też dodać jako parametr pierwszej komendy (git svn clone …. .).
Mając swoją kopię svn-owego repozytorium możemy pracować zgodnie z workflowem gitowym jaki Tobie odpowiada.
Do pełnej używalności pozostają nam dwie dodatkowe komendy:
git svn rebase (robi update z svna) oraz git svn dcommit (wysyła commity do svn-a).
Tym sposobem mamy narzędzie, w którym możemy pracować zupełnie offline w stosunku do svn-a, możemy pracować na branch-ach, możemy robić commity lokalne i dowolnie kształtować nasz kod a na koniec wypchnąć całość do svn-a.
Osobiście pracuję tak, że w gałęzi master w ogóle nie pracuję. Wszystko co robię, robię w gąłęzi dev i/lub bledy. Następnie przed wrzuceniem zmian do svn-a robię w gałęzi master git svn rebase co pobiera mi zmiany w repozytorium. Za pomocą rebase-a zmiany z gałęzi dev wrzucam do gałęzi master i później git svn dcommit wypycham zmiany spowrotem do svn-a. Plus takiego rozwiązania jest taki, że w svn-ie historia zmian jest cały czas ładna liniowa i nie ma żadnych commitów typu merge (gdybym zamiast rebase korzystał z merge). Z punktu widzenia współpracowników na repozytorium w ogóle nie widać, że gdzieś tam zagnieździł się git. Jedyne co może wzbudzać podejrzenie to 10-20 commitów w odstępach 5-20 sekundowych (ninja dev ;P)
Co do samych narzędzi do git-a to poza SourceTree o którym pisałem wcześniej najwygodniej pracuje mi się w konsoli (o dziwo) ale nie w tej konsoli git-owej tylko w posh-git -cie 
