Git i Mercurial: zalety jednego i drugiego

Z Gitem pracuję na co dzień już dobre trzy lata, czy nawet więcej. I kocham ten soft. Uważam go za najlepsze narzędzie z jakim kiedykolwiek spotkałem się w swojej programistycznej karierze – we wszystkich kategoriach. Nic nigdy aż tak bardzo mi nie zaimponowało. Zresztą rozwodzić się nie będę – o tym można poczytać we wszystkich moich postach dotyczących Gita.

Nie mam jednak w zwyczaju wpadać w jedno narzędzie i od razu zakładać, że jest ono “the only one”. Z tego też powodu do projektów pobocznych przez dość długi czas używałem Mercuriala – żeby porównaćff. Bo a nuż będzie JESZCZE lepiej?

Nie było. Dla mnie osobiście Git podoba się bardziej. Zaznaczyć jednak muszę, że oba te narzędzia są znakomite. Nie śmiem twierdzić że”git jest cool a hg jest be”, bo tak nie jest. Po prostu gdybym miał komukolwiek rekomendować system kontroli wersji to zawsze polecę Gita – z mojej perspektywy jest zwyczajnie o wiele bardziej wygodny i lepiej sprawdza się dla moich potrzeb. Ale i Mercurial ma obszary, w których jest niedościgniony.

Byłem o swój pogląd na tą sprawę pytany niejednen już raz, więc publikuję porównawczą listę ZALET Gita w stosunku do HG i ZALET HG w stosunku do Gita. Powstawała ona przed dość długi czas (z rok?) podczas pracy raz z jednym, raz z drugim systemem na co dzień, na zmianę.

Zalety Gita:

• wszystko mamy “prosto z pudełka”, nie trzeba szukać na wszystko extensions i zastanawiać się czy inne osoby w zespole też je mają; co prawda rozszerzenia HG potrafią robić masę przydatnych rzeczy, ale trzeba wiedzieć że takie i takie extension istnieje a potem je włączyć
• przy commicie, oprócz standardowych informacji, Git pokazuje również jakie zmiany NIE SĄ uwzględnione , tzn co pomijamy tworząc commita – bardzo przydatne, w HG tego mi brakowało
• Git Bash – konsola na sterydach, cudny sposób pracy z Gitem, oferuje tab completion, stale widoczną informację o aktualnej gałęzi i wiele innych…
• dzięki “tracking branches” mam w bashu info jaka jest relacja mojej lokalnej gałęzi w stosunku do zdalnej, czyli ile która commitów jest do przodu (“Your branch is ahead of ‘origin/master’ by 2 commits”)
• komenda “interactive add” wydaje mi się o wiele wygodniejsza niż analogiczne “hg record”
• po merge – automatycznie sugeruje commit msg
• index – Git jako jedyny system kontroli wersji oferuje mechanizm “staging area”, czyli miejsce na przygotowanie kolejnego commita zanim faktycznie zostanie on utworzony; po latach używania mogę z całą stanowczością stwierdzić że jest to naprawdę cudny wynalazek i w HG wyraźnie czuć jego brak (można o tym poczytać więcej m.in. tu i tu, a najlepiej zapytać wujka Google’a o “git index” lub “git staging area”; Binga nie pytajcie bo on nic nie wie;) )
• model gałęzi wydaje mi się tutaj bardziej naturalny i przydatny- changeset nie posiada “wspawanej na stałe” nazwy gałęzi do której go zacommitowano, może być przenoszony między gałęziami, co daje dużo więcej swobody…
• …co prawda w HG można użyć mechanizmu “bookmarks” żeby zasymulować takie zachowanie, jednak nadal metadane changesetu będą miały nazwę gałęzi, a nazwy bookmarków nie są domyślnie synchronizowane między repozytoriami (i nie są widoczne np. w bitbucket); link do tekstu z detalami poniżej
• śledzi zawartość plików, a nie same pliki jako takie – więc operacje jak copy/move/rename są wykrywane automatycznie

Zalety Mercuriala/HG:

• bardziej czytelna, lepiej zorganizowana pomoc, przyjazna użytkownikowi i łatwiejsza w nawigacji oraz “konsumpcji”
• łatwiej korzysta mi się z file name patterns niż w Gicie, parametry -I i -X rulezzz!
• hg serve – wbudowany lokalny serwer http, raczej tylko do hobbystycznych zastosowań, ale i tak fajna sprawa; w Gicie jest mechanizm “git daemon”, ale z tego co się orientuję to tylko na linuxie, no i nie oferuje wygodnego dostępu przez www
• hg archive – błyskawiczny sposób na wypisanie gdzieś całej rewizji (w Gicie też nie jest to skomplikowane, ale w Mercurial prościej to osiągnąć)
• nie ma potrzeby wpisywania calych komend – zostaną odgadnięte w miarę możliwości (np hg pus zamiast push, hg fet zamiast fetch, hg up zamiast update, etc..)… z drugiej strony w Git bash działa tab completion, a taką samą praktykę można zastosować na poziomie parametrów dla komend (np git commit –am zamiast pełnego –amend)
• niby prostsze w obsłudze dla użytkowników Windows – ale szczególnie już w roku 2012 to kwestia bardzo dyskusyjna

Być może niektóre z tych punktów są już nieaktualne. Być może nigdy aktualne nie były. To luźne notatki, do których co i rusz coś dopisywałem na przestrzeni wielu miesięcy.

Dwa linki jako bonus:

• Mercurial for Git users – ten dokument jasno pokazuje jak podobne są do siebie te systemy; oraz dlaczego jednak warto zwrócić się w stronę Gita mimo że jest to tekst z oficjalnej strony Mercuriala;)
• No, mercurial branches are still not better than git ones – bardziej szczegółowy opis różnic między modelem gałęzi w Gicie i HG, i dlaczego te w Gicie są lepsze (bo są)

Jak widać całkowicie pomijam w tym poście jakiekolwiek inne systemy kontroli wersji. Pisałem czasami o alternatywach, o czym można poczytać pod tagiem “version control“, ale od lat dla mnie one nie istnieją. Powinny zostać skasowane z powierzchni internetu, ew. zostać wrzucone w globalny katalog nazwany “jak nie powinno się rozwiązywać problemów związanych z tworzeniem oprogramowania”. Kropka.

Oczywiście zapraszam do dyskusji:).