Kodzić po ludzku czyli jak się pozbyć svn-a

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 Uśmiech