BartoIT Blog

Długi czas przerwy minął od ostatniego wpisu. Tym razem jednak wpis z propozycją radzenia sobie w przypadku, gdy w Twojej firmie jest używany SVN, ale Ty nie bardzo jesteś entuzjastą tego systemu kontroli wersji. Postanowiłem po już półtora roku pracy opisać jak swoją ścieżkę na drodze po SVN’ie.

Zaskoczenie

To jest ten moment, kiedy dowiadujesz się po studiach, że jest coś takiego jak Subversion. Mówisz sobie, że to nie ma różnicy, dopóki nie postanawiasz, że wpiszesz do okna wyszukiwarki…

Git vs SVN

No i czytasz, czytasz, czytasz i nastawiasz się negatywnie. Brak entuzjazmu utwierdza Cię w tym, kiedy próbujesz zrobić jakiekolwiek zmiany, a nie używasz poleceń dla SVN’a i zastaje Cię conflict tree.

Szukanie odpowiedzi

Poszukujesz wśród zespołu odpowiedzi, dlaczego jest tak, a nie inaczej. Następnie pojawia się na horyzoncie coś pokroju światła latarni na tym wzburzonym morzu konfliktów, których nie doświadczyłeś przez ostatnie lata pisania w gicie projektów do szuflady, projektów na zaliczenie na studiach i w wielu innych miejscach. Szczęśliwie klikałem po GUI, uznając GIT’a za bardzo dobry system do zarządzania kontrolą wersji projektu.

Sięgasz więc po polecenia z serii git-svn. Ale…

Nie jesteś na to gotów

Przerasta Cię to. Do tej pory używałeś konsoli od gita tylko w tutorialu, aby zaliczyć przedmiot na studiach. Znalazłeś przecież dobrego clienta z GUI tak intuicyjnym, że nie potrzebowałeś znajomości konsoli. Musisz więc pogodzić się z tym, że będziesz używać SVN’a, aż czegoś nie wymyślisz.

Kurs gita

Proszę, nie traktuj tego jako reklamy, ale tutaj na drodze pojawił się kurs gita Macieja Aniserowicza, który pomógł mi wrócić na słuszną drogę. Co więcej, w jednym z materiałów załączył proponowany git workflow, który postanowiłem wypróbować, mimo że mam SVN’a.

Do odważnych świat należy

Całość tej akcji zaczęła się dosyć niedawno. W zasadzie kurs, mimo że dawno temu kupiony w przedsprzedaży wciąż leży w 100% nieukończony. Ale jestem już na tym poziomie, że nie boję się konsoli gita. 2 – 3 tygodnie wstecz postanowiłem ponownie spróbować polecenia git-svn.

Domyślnie propozycja jest taka, aby za pomocą tego polecenia wyciągnąć sobie trunka, branche i tagi. Ja jednak postanowiłem dostroić to trochę pod siebie i zminimalizować ryzyko konfliktów, które mogłyby powstać przy używaniu gita.

• Source: Owned by the author

Teraz jest najlepszy moment, abym na to zwrócił uwagę. W projekcie, w którym biorę udział, nie występowały externale svn-owe, był w to projket pisany od zera i miałem wydzieloną swoją działkę, za którą byłem odpowiedzialny. Konflikty zawsze pojawiały się u mnie przy mergowaniu z trunkiem. Z czasem coraz mniejsze, aż w pewnym momencie, był to już jeden plik, w kółko ten sam, główny CMakeLists, który u każdego był troszkę rozbieżny, a przy mergowaniu do trunka zawsze z nim były „kolorowe jarmarki”.

Co daje mi ten sposób postępowania?

Moja natura nie bardzo pozwala mi na to, abym mógł swobodnie robić bałagan, wiedząc, że kogoś może to w każdej chwili zacząć uwierać. Dlatego też mimo tego że nie musiałem się obawiać, że ktoś zajrzy mi w logi, aby zobaczyć co tam commituję na branchu, to używanie z poziomu Tortoise SVN’a nie jest dla mnie najwydajniejsze.
Głównym moim celem było osiągnięcie, abym z commitów mógł korzystać jak z Ctrl+Z na sterydach. Dodatkowym plusem pracy w ten sposób jest to, że do najbliższego commita po drugiej stronie mam swój bałagan tylko dla siebie. To daje mi komfort swobodniejszego pisania komentarzy do commita i pozwala trochę się rozprężyć, bo niewątpliwie źle wygląda 10 commitów, które niewiele w kodzie zmieniają i nazywają się „commit roboczy”, bo nie przyszło Ci w tym czasie nic mądrzejszego do głowy.

Fakt, że w tym czasie mocno też rozwija się u mnie podejście do wytwarzania kodu. Teraz w ostatnim czasie, kiedy podjąłem się refaktoryzacji, tego, co wytworzyłem z dnia na dzień, z commita na commit spada mi entuzjazm i hura optymizm do wpadania w furię pisania kodu na zasadzie przelewania pierwszej myśli na papier, jak to robię tutaj na blogu.

Oprócz możliwości schowania się w swojej maszynie,lokalnie , czuję się komfortowo, bo mimo że znam teraz Subversion na satysfakcjonującym mnie poziomie (czytaj – zwinnie unikam konfliktów i zwinnie sobie z nimi radzę), tak używanie gita sprawia, że czuję się jeszcze bardziej komfortowo, pracując z nim.

No i ogromny pozytyw jest także z tego, że commity lokalnie lecą jak z karabinu. Robi się je naturalnie i bez zastanowienia, kiedy czuję, że tutaj powinienem mieć punkt odniesienia do stanu repozytorium. Natomiast obowiązek mergowania do mastera i utrzymania liniowej historii sprawia, że przy transporcie do SVN’a cały ten bałagan zostaje po drugiej stronie, u mnie, na komputerze.

Minusy

Bałagan jest nieprzenośny. Nie wiem do końca, czy traktować to jako minus, ale jeżeli po całym dniu pracy na jednej maszynie, chcę później kontynuować pracę na innej, to wymusza to na mnie mergowanie całego dnia do mastera i wykonanie commita w stronę brancha svn-owego. Konsekwencją jest rozbieżność stanów. Załóżmy, że chciałbym się wrócić do któregoś ze stanów na drugiej maszynie, bo doszedłem do wniosku, że dwa commity temu było lepiej. W tym momencie ręce mam związane i albo decyduje się na żmudną próbę odtworzenia ręcznie z pamięci poprzedniego stanu, albo mam stan postojowego nad danym zagadnieniem, żeby nie rozgrzebywać tego jeszcze bardziej.

Drugim minusem jest brak kopii zapasowej stanów lokalnego gita w innych miejscach. W pracy wyłączenie z gitem lub wyłącznie z svn-em mam gwarantowany ciągłą kopię (dopóki, dopóty rzecz jasna nie padnie serwer). W przypadku wymieszania gita z svn-em to, co zrobiłem lokalnie, pozostaje lokalnie, bo zakładam, że w naszym interesie nie leży przenoszenie wszystkich commitów do brancha svn-a 1:1.

Podsumowując

Na pewno nie mogę powiedzieć, że żałuję, że pracuję na SVN-ie. Na tym etapie radzę już sobie zgrabnie z problemami związanymi z konfliktami. Teraz jeszcze mam ten przywilej, że mam zapas czasu przed oddawaniem kodu i w zasadzie proces oddawania do trunka przestał być stresujący.

Wielkim plusem całej tej historii jest efekt uboczny w postaci szybszego przyswojenia posługiwania się gitem w bardziej rozbudowany sposób niż init – commit – pull – push. A używanie dwóch systemów jednocześnie uważam teraz z perspektywy czasu za ciekawe i bezcenne doświadczenie.