Git i Mercurial: zalety jednego i drugiego

13

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:

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:).

Share.

About Author

Programista, trener, prelegent, pasjonat, blogger. Autor podcasta programistycznego: DevTalk.pl. Jeden z liderów Białostockiej Grupy .NET i współorganizator konferencji Programistok. Od 2008 Microsoft MVP w kategorii .NET. Więcej informacji znajdziesz na stronie O autorze. Napisz do mnie ze strony Kontakt. Dodatkowo: Twitter, Facebook, YouTube.

13 Comments

  1. Od dawna również używam HG i Git, jednak od dłuższego czasu brakowało mi zintegrowanego środowiska zawierającego "implementację" Scruma (sprinty, user stories, bugi etc.) zintegrowanego z systemem kontroli wersji. Dlatego od 2-3 tygodni testuję i używam TFS w wersji hostowanej przez Microsoft, który z VS2012 działa rewelacyjnie (nie przywiesza się, żeby pobrać plik z serwera itp., czego nie można powiedzieć o VS2010). Także nie skreślałbym innych systemów kontroli wersji niż HG i GIT.
    Jeśli ktoś byłby zainteresowany TFS hostowanym przez Microsoft (do 5 użytkowników za darmo) to zapraszam: http://tfs.visualstudio.com/

  2. Michał, nie spodziewałem się że doczekam dnia w którym ktoś na moim blogu będzie rekomendował TFS:). Zdecydowanie się NIE zgadzam, to właśnie TFS powinien być głównie zmieciony z powierzchni ziemi. Pisałem o nim już kilka razy i chyba wszystko co miałem do przekazania – przekazałem: http://www.maciejaniserowicz.com/?tag=/tfs

  3. @Michał i @Procent – MS oferuje "Microsoft Scrum". Troche to utrudnia prawdziwy Agile, ponieważ process Scrum powinien być ŁATWO dostosowywalny do potrzeb, a nie z góry narzucony. Oczywiście reguły TFS można zmieniać ale nie jest to rzecz prosta. Jeżeli komuś zależy na skutecznie zarządzalnym Scrumie to polecam Kanbanery.com, które dobrze integruje się z GitHubem.

  4. @Procent – TFS w wersji 2010 (o 2008 nie wspomnę), faktycznie był toporny, czego nie mogę powiedzieć o 2012. Ja do tej pory nie napotkałem na problem, który wystąpił u Gutka, fakt, miałem parę problem z nieuruchamiającym się narzędziem do merge'a, ale po restarcie VS wszystko działało i mogę merge'ować.
    Zarejestrowałem się na kanbanery.com i wygląda mi to bardziej na tablicę kanbanową, bez Product Backlogu, sprintów, burndown'a, nie mogę robić też forecastów, w którym sprincie mniej więcej będzie robiona dana rzecz i właśnie to wg mnie jest problemem tego typu softu, jest po prostu ubogi.

  5. @Michał – masz rację co do narzędzi planowania. Zatem dla tych, którzy działają na mniejszą skalę Kanbanery ma kilka podstawowych opcji w zakładce "Reports" (Cumulative Flow Chart, Lead and Cycle Time, Task Distribution).

    @Procent i @Jacek GitLab super się sprawdza jako darmowa esencja GitHuba. Jeżeli firma nie chce płacić za GitHub to GitLab po prostu wymiata mózg. Pierwszy raz się spotkałem z prawdziwym procesem Code Review dzięki temu narzędziu (Merge Requests). Instalacja GitLaba wydaje się długa ale jest to bardzo prosty proces. Wystarczy przysiąść na godzinkę. W razie czego mogę udostępnić VM.

  6. Do zalet Mercuriala dodałbym jeszcze numerowanie rewizji kolejnymi liczbami obok hashy.

    Poza tym zespół tworzący Merkuriala próbuje ogarnąć sprawę niezmienniczości historii (immutable history) w taki sposób, żeby ta historia mogłaby jednak być zmieniana ;-). Sprawa jest niezwykle ciekawa i polega na tym, że można zmieniać changesety, które już ktoś od nas pobrał. Przy następnym pobraniu stare changesety zmienią się u niego na przestarzałe a Mercurial zrobi sam rebase lokalnych zmian na nowych nowych changesetach. Brzmi to może skomplikowanie ale w praktyce działa dość dobrze. Tu jest artykuł/podręcznik na ten temat -> http://hg-lab.logilab.org/doc/mutable-history/html/index.html

  7. Boży,
    O tej historii to ciekawa sprawa, dzięki, poczytam sobie:) Dość kontrowersyjna kwestia, ale faktycznie systemowe rozwiązanie tego problemu to interesujący pomysł.
    Co do 'numerycznych' rewizji to nie postrzegam tego jako zaletę – ot, raczej ciekawostka. Te numery i tak są tylko lokalne.

  8. Cześć Procent!

    Bardzo się cieszę, że udało Ci się powrócić do pisania. Ja z kolei jakoś nie mogę się do gita przekonać. Bardziej mi po drodze z Bazaarem.