Umarł GitLab niech żyje git czyli co zrobić zepsuje się git

git sie zepsul co robic

Git to repozytorium kodu a repozytorium kodu to jedno z podstawowych narzędzi pracy programisty. Dzisiaj pół internetu pisze, że GitLab – serwis do hostowania repozytoriów git – zaliczył poważną wpadkę. Trudno, zdarza się ale jakie można z tego wyciągnąć wnioski?

Single Point Of Failure

Centralne repozytorium kodu ma tą wielką zaletę, że jest centralne. SVN-y, SourceSafe-y i inne tego typu repozytoria kodu mają wielką zaletę – jedno źródło prawdy. To też najsłabsza strona – bo jak padnie serwer to nie ma nic. Na komputerach programistów pozostanie wprawdzie kod źródłowy ale bez jakiejkolwiek historii. Na ten wypadek warto mieć zbudowany odpowiedni plan backupu a właściwie kilku backupów – w chmurze, w szafie ogniotrwałej, offsite. Warto by było od czasu do czasu sprawdzić czy z backupu da się cokolwiek odzyskać. Generalnie w sytuacji awarii serwera odgrzebujemy backup, przywracamy repozytorum i pracujemy dalej no chyba, że padł sprzęt a my nie mamy zapasu, wtedy zamawiamy nowy, przywracamy co trzeba i pracujemy dalej. Już po kilku godzinach lub dniach spokojnie sobie pracujemy. Czy nie da się tego jakoś usprawnić?

Git na ratunek!

Dzisiejsza awaria GitLaba przeraziła całkiem sporą część internetu. Nie ma się co dziwić, bo wyobraź sobie, że nagle nie masz dostępu do swojego repozytorium. Mi się taka akcja zdarzyła w najgorszym możliwym momencie – w czasie wdrożenia przy sporej presji czasowej. Nagle repozytorium git-owe padło a dokładniej padł vpn do serwera ileś tam kilometrów dalej. Dwie osoby pracują nad kodem – wiadomo, ostatnie poprawki – czas ucieka, zmęczenie doskwiera a tu co? mamy ręcznie kod mergować? Na szczęście git to rozproszone repozytorium kodu a nie jak wspomniane w pierwszym akapicie „centralne repozytoria”. Rozproszone repozytorium oznacz tyle, że masz lokalną kopię całego repozytorium na komputerze. To oznacz, że bardzo szybko możesz postawić inne repozytorium. W moim przypadku sprowadziło się to do założenia repozytorium na bitbuckecie (bo tam można za darmo hostować prywatne repozytorum) a potem wykonania dwóch komend:


    git remote add backup git@bitbucket.org:.../.....git

    git push backup master

To spowodowało, że w chmurze pojawiła się pełna kopia repo i mogliśmy spokojnie pracować dalej. Cała operacja trwała może 5 minut razem z założeniem konta i wysłaniem danych.

Czy awaria gita to jakaś tragedia?

No właśnie, wracając do samej awarii gitlab-a (ale i innch, githuba, bitbucket-a i tych wszystkich tajnych firmowych „bezpiecznych” repozytoriów), jeśli tylko nasze repozytorium jest rozproszone to w 5 minut jesteśmy wstanie postawić kopię i pracować dalej. Taka awaria będzie dla nas mikro przeszkodą a nie tragedią blokującą pracę na godziny a czasem nawet na dni. To jest siła posiadania kopii repozytorium lokalnie…

… z małym zastrzeżeniem, jeśli regularnie commitujemy i regularnie pushujemy do zewnętrznego repozytorium.

 

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

Graficzny klient do gita–SourceTree jest już dostępny

Kilka tygodni firma Atlassian ogłosiła zamkniętą betę swojego (podobno jednego z najlepszych)klientów git-a Wczoraj wyszedł z wersji beta i jest oficjalnie dostęny.

http://www.sourcetreeapp.com/

image

Od czasów bety używam go do oglądania repozytorium i czasem do commitowania i wygląda, że jest całkiem przyzwoity. Myślę, że warto spróbować.