Jaka jest różnica między Mercurial a Git?

Pracuję nad Mercurialem, ale zasadniczo uważam, że oba systemy są równoważne. Obie pracują z tymi samymi abstrakcjami: serią migawek (zestawów zmian), które składają się na historię. Każdy zestaw zmian wie, skąd pochodzi (macierzysty zestaw zmian) i może mieć wiele zestawów zmian potomnych. Ostatnie rozszerzenie hg-git zapewnia dwukierunkowy most pomiędzy Mercurial i Git i pokazuje ten punkt.

Git mocno koncentruje się na mutacji tego wykresu historii (z wszystkimi konsekwencje, które pociągają za sobą) podczas gdy Mercurial nie zachęca do przepisywania historii, ale i tak jest to łatwe do zrobienia i konsekwencje tego są dokładnie takie, jakich powinieneś się spodziewać (to znaczy, jeśli zmodyfikuję zestaw zmian, który już masz, twój klient zobaczy go jako nowy, jeśli wyciągniesz ode mnie). Tak więc Mercurial ma stronniczość wobec poleceń nieniszczących.

Używam Linuksa, ale najwyraźniej TortoiseHg jest szybszy i lepszy od odpowiednika Git na Windows (ze względu na lepsze wykorzystanie słabego systemu plików Windows). Both http://github.com i http://bitbucket.org zapewnij hosting online, usługa na Bitbucket jest świetna i responsywna(nie próbowałem github).

Wybrałem Mercurial, ponieważ jest czysty i elegancki-zniechęciły mnie Skrypty shell/Perl / Ruby, które dostałem z Gitem. Spróbuj rzucić okiem na git-instaweb.sh Plik jeśli chcesz wiedzieć o co mi chodzi: jest to skrypt shell , który generuje skrypt Ruby , który chyba działa na serwerze. Skrypt powłoki generuje inny skrypt powłoki, aby uruchomić pierwszy skrypt Ruby. Jest też trochę Perla , na dobrą sprawę.

Podoba mi się post na blogu który porównuje Mercurial i Git z Jamesem Bondem i Macgyverem -- Mercurial jest jakoś bardziej low-key niż Git. Wydaje mi się, że osoby używające Mercurialu nie są pod takim wrażeniem. Jest to odzwierciedlone w tym, jak każdy system robi to, co Linus opisał jako "najfajniejsze połączenie w historii!". W Git możesz połączyć się z niepowiązanym repozytorium wykonując:

git fetch <project-to-union-merge>
GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD
GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u
git-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files)
cp .git/FETCH_HEAD .git/MERGE_HEAD
git commit

Te polecenia wydają mi się dość tajemnicze. W Mercurial robimy:

hg pull --force <project-to-union-merge>
hg merge
hg commit

Zauważ, że polecenia Mercurial są proste i wcale nie specjalne-jedyną niezwykłą rzeczą jest flaga --force do hg pull, która jest potrzebna, ponieważ Mercurial zakończy działanie w przeciwnym razie, gdy wyciągniesz z niepowiązanego repozytorium. To właśnie takie różnice sprawiają, że Mercurial wydaje mi się bardziej elegancki.

Git to platforma, Mercurial to" tylko " aplikacja. Git jest wersjonowaną platformą systemu plików, która jest dostarczana z aplikacją DVCS w pudełku, ale jak zwykle dla aplikacji platformowych, jest bardziej złożona i ma bardziej chropowate krawędzie niż aplikacje skupione. Ale oznacza to również, że VCS Gita jest niezwykle elastyczny i istnieje ogromna głębia Nie-source-control rzeczy, które możesz zrobić z Gitem.

To jest istota różnicy.

Git najlepiej rozumieć od podstaw – od format repozytorium w górę. Git Talk Scotta Chacona to doskonały podkład do tego. Jeśli spróbujesz użyć Gita nie wiedząc, co dzieje się pod maską, w pewnym momencie będziesz zdezorientowany (chyba że będziesz trzymać się tylko bardzo podstawowej funkcjonalności). Może to zabrzmieć głupio, kiedy wszystko czego potrzebujesz to DVCS do codziennego programowania, ale geniuszem Gita jest to, że format repozytorium jest bardzo prosty i Ty {7]}możesz {8]} dość łatwo zrozumieć całą operację Gita.

Dla kilka bardziej technicznych porównań, najlepsze artykuły jakie widziałem osobiście to Dustin Sallings':

• różnice między Mercurial i Git
• Reddit wątek gdzie doświadczony Dustin odpowiada na własne pytania git neophyte

On właściwie używał zarówno DVCSs szeroko i dobrze je rozumie - i skończyło się wolą git.

Duża różnica jest na Windows. Mercurial jest wspierany natywnie, Git nie. możesz uzyskać bardzo podobny hosting do github.com z bitbucket.org (właściwie nawet lepiej, gdy masz darmowe prywatne repozytorium). Używałem msysGit na chwilę, ale przeniósł się do Mercurial i był bardzo zadowolony z niego.

Jeśli jesteś programistą Windows poszukującym podstawowej kontroli rozłączonych wersji, skorzystaj z Hg. Uznałem Git za niezrozumiały, podczas gdy Hg był prosty i dobrze zintegrowany z powłoką Windows. Ściągnąłem Hg i wykonałem ten tutorial (hginit.com) - dziesięć minut później miałem lokalnego repo i wróciłem do pracy nad moim projektem.

Myślę, że najlepszy opis o "Mercurial vs. Git" to:

"Git to Wesley Snipes. Mercurial to Denzel Washington "

Są prawie identyczne. Najważniejszą różnicą, z mojego punktu widzenia (mam na myśli powód, który skłonił mnie do wyboru jednego DVC nad drugim) jest sposób, w jaki oba programy zarządzają gałęziami.

Aby uruchomić nową gałąź, za pomocą Mercurial, wystarczy sklonować repozytorium do innego katalogu i zacząć się rozwijać. Następnie ciągniesz i łączysz się. W git, musisz jawnie nadać nazwę nowej gałęzi tematycznej, której chcesz użyć, a następnie rozpocząć kodowanie używając tego samego katalog .

W skrócie, każda gałąź w Mercurial potrzebuje własnego katalogu; w git zazwyczaj pracujesz w jednym katalogu. Zmiana gałęzi w Mercurial oznacza zmianę katalogów; w git oznacza poproszenie git o zmianę zawartości katalogu za pomocą git checkout.

Jestem szczery: Nie wiem, czy można zrobić to samo z Mercurial, ale ponieważ zwykle pracuję nad projektami internetowymi, używanie zawsze tego samego katalogu z Gitem wydaje mi się bardzo wygodne, ponieważ nie muszę re-configure Apache and restart it and I don ' t mess my filesystem everyone I branch.

Edit: jak zauważył Deestan, Hg ma nazwane gałęzie , które mogą być przechowywane w jednym repozytorium i pozwalają deweloperowi na przełączanie gałęzi w ramach tej samej kopii roboczej. gałęzie git nie są dokładnie takie same jak gałęzie Mercurial nazwane, w każdym razie: są trwałe i nie wyrzucają gałęzi, jak w git. Oznacza to, że jeśli używasz nazwanej gałęzi do zadań eksperymentalnych, nawet jeśli zdecydujesz się nigdy Scal go zostanie on zapisany w repozytorium. To jest powód, dla którego Hg zachęca do używania klonów w eksperymentalnych, krótkich zadaniach i nazwanych gałęziach w długich zadaniach, takich jak gałęzie wydania.

Powód, dla którego wielu użytkowników Hg preferuje klony zamiast nazwanej gałęzi, jest o wiele bardziej społeczny lub kulturowy niż techniczny. Na przykład w przypadku ostatnich wersji Hg możliwe jest nawet zamknięcie nazwanej gałęzi i rekurencyjne usuwanie metadanych z zestawów zmian.

Po drugiej stronie, git zachęca do używania "nazwanych gałęzi", które nie są stałe i nie są przechowywane jako metadane w każdym zestawie zmian.

Z mojego osobistego punktu widzenia, model Gita jest głęboko związany z koncepcją nazwanych gałęzi i przełączania się między gałęziami i innymi w tym samym katalogu; hg może zrobić to samo z nazwanymi gałęziami, ale mimo to zachęca do używania klonów, które osobiście nie lubię zbytnio.

Jest jedna Ogromna różnica pomiędzy git i mercurial ; sposób reprezentowania każdego commita. git reprezentuje commity jako migawki, podczas gdy mercurial reprezentuje je jako diffy.

Co to oznacza w praktyce? Cóż, wiele operacji jest szybszych w git, takich jak przejście na inny commit, porównanie commitów, itp. Szczególnie jeśli te commity są daleko.

AFAIK nie ma żadnej przewagi w podejściu mercuriala.

Nic. Oboje robią to samo, oboje wykonują po równo. Jedynym powodem, dla którego powinieneś wybrać jeden nad drugim, jest pomoc w projekcie, który już go używa..

Innym możliwym powodem wyboru jest aplikacja lub usługa, która obsługuje tylko jeden z systemów.. Na przykład, zdecydowałem się nauczyć Gita z powodu github ..

Również porównanie google (choć trochę stare, zrobione w 2008 roku)

Http://code.google.com/p/support/wiki/DVCSAnalysis

Jeśli dobrze je Rozumiem (i jestem daleki od eksperta w każdej z nich) zasadniczo każdy z nich ma inną filozofię. Pierwszy raz używałem mercurial przez 9 miesięcy. Teraz użyłem git dla 6.

Hg to oprogramowanie do kontroli wersji. Jego głównym celem jest śledzenie wersji oprogramowania.

Git jest systemem plików opartym na czasie. Jego celem jest dodanie nowego wymiaru do systemu plików. Większość ma pliki i foldery, git dodaje czas. Że działa rewelacyjnie jako VCS jest produktem ubocznym jego konstrukcji.

W hg, jest historia całego projektu, który zawsze stara się utrzymać. Domyślnie wierzę, że hg chce wszystkich zmian we wszystkich obiektach przez wszystkich użytkowników podczas pchania i ciągnięcia.

W git jest tylko Pula obiektów i plików śledzących (gałęzi/głowic), które określają, który zestaw tych obiektów reprezentuje drzewo plików w danym stanie. Podczas pchania lub ciągnięcia git wysyła tylko obiekty potrzebne do poszczególnych gałęzi, które pchasz lub ciągnięcie, czyli mały podzbiór wszystkich obiektów.

Jeśli chodzi o git, nie ma "1 projektu". Możesz mieć 50 projektów w jednym repo i git by się tym nie przejmował. Każdy z nich może być zarządzany oddzielnie w tym samym repo i żyć dobrze.

Koncepcja gałęzi Hg to odgałęzienia od głównego projektu lub odgałęzienia od odgałęzień itp. Git nie ma takiej koncepcji. Gałąź w git jest tylko stanem drzewa, wszystko jest gałęzią w git. Który oddział jest oficjalny, aktualny lub najnowszy nie ma żadnego znaczenia w git.

             o---o---o
            /        
o---o---o---o---o---o---o---o
         \         /
          o---o---o

o---o---o---o---o

o---o---o---o
         \
          o---o

o---o---o---o

W rzeczywistości w niektórych aspektach Pokazywanie gałęzi w git nie ma nawet sensu.

Jedna rzecz to jest bardzo mylące dla dyskusji, git i mercurial mają coś, co nazywa się "gałęzią", ale nie są zdalnie tymi samymi rzeczami. Gałąź w mercurial pojawia się, gdy istnieją konflikty między różnymi repo. Gałąź w git jest najwyraźniej podobna do klonu W hg. Ale klon, choć może dać podobne zachowanie jest zdecydowanie nie to samo. Rozważ, że próbuję ich w git vs hg używając chromium repo, który jest dość duży.

$ time git checkout -b some-new-branch
Switched to new branch 'some-new-branch'

real   0m1.759s
user   0m1.596s
sys    0m0.144s

A teraz w hg używając klon

$ time hg clone project/ some-clone/

updating to branch default
29387 files updated, 0 files merged, 0 files removed, 0 files unresolved.
real   0m58.196s
user   0m19.901s
sys    0m8.957

Oba są gorące biegi. Przejechałem je dwa razy i to jest drugi bieg. hg clone jest tym samym co git-new-workdir. Oba tworzą zupełnie nowy, działający katalog, prawie tak, jakbyś wpisał cp -r project project-clone. To nie to samo co tworzenie nowej gałęzi w git. Jest znacznie cięższa. Jeśli istnieje prawdziwy odpowiednik rozgałęzienia git W hg to nie wiem co to jest.

Rozumiem, że na pewnym poziomie hg i git mogą być w stanie robić podobne rzeczy. Jeśli tak, to nadal istnieje ogromna różnica w przepływie pracy, do którego prowadzą. W git, typowym przepływem pracy jest tworzenie gałęzi dla każdej funkcji.

git checkout master
git checkout -b add-2nd-joypad-support
git checkout master
git checkout -b fix-game-save-bug
git checkout master
git checkout -b add-a-star-support

To właśnie stworzyło 3 gałęzie, każda oparta na gałęzi zwanej master. (Jestem pewien, że jest jakiś sposób w git, aby zrobić te 1 linijki zamiast 2)

Teraz do pracy nad jednym po prostu zrobić

git checkout fix-game-save-bug

I zacznij pracować. Commit rzeczy, itp. Przełączanie między gałęziami nawet w projekcie tak dużym jak chrome jest prawie natychmiastowe. Nie wiem jak to zrobić W hg. To nie jest część żadnych tutoriali, które czytałem.

Git ma pomysł na scenę. Możesz myśleć o tym jak o ukrytym folderze. Kiedy zatwierdzasz, zatwierdzasz tylko to, co jest na scenie, a nie zmiany w roboczym drzewie. To może zabrzmieć dziwnie. Jeśli chcesz zatwierdzić wszystkie zmiany w drzewie roboczym, wykonaj git commit -a, który dodaje wszystkie zmodyfikowane pliki do stage, a następnie zatwierdzi oni.

Jaki jest więc sens tej sceny? Możesz łatwo oddzielić swoje commity. Wyobraź sobie, że edytowałeś joypad.cpp i gamesave.cpp i chcesz je zatwierdzić osobno

git add joypad.cpp  // copies to stage
git commit -m "added 2nd joypad support"
git add gamesave.cpp  // copies to stage
git commit -m "fixed game save bug"

Git posiada nawet komendy, które decydują, które linie w tym samym pliku chcesz skopiować do stage, dzięki czemu możesz podzielić te commity osobno. Dlaczego chcesz to zrobić? Ponieważ jako oddzielne commity inni mogą pobierać tylko te, które chcą lub jeśli wystąpił problem, mogą przywrócić tylko ten commit, który miał problem.

Na blogu versioncontrolblog znajduje się dynamiczna tabela porównawcza, na której można porównać kilka różnych systemów kontroli wersji.

Oto tabela porównawcza pomiędzy git, hg i bzr.

Istnieją dość znaczące różnice, jeśli chodzi o pracę z gałęziami (szczególnie krótkoterminowymi).

Jest to wyjaśnione w tym artykule (BranchingExplained) , który porównuje Mercurial z Gitem.

Czy są jacyś współpracownicy z Windowsem w Twoim projekcie?

Ponieważ jeśli istnieją, GUI Git-for-Windows wydaje się niewygodne, trudne, nieprzyjazne.

Mercurial-on-Windows, dla kontrastu, jest bezmyślny.

Jedna rzecz do zauważenia między mercurial of bitbucket.org a git z Githuba jest, mercurial może mieć tyle prywatnych repozytoriów, ile chcesz, ale github musisz uaktualnić do płatnego konta. Dlatego wybieram bitbucket, który wykorzystuje mercurial.

W zeszłym roku oceniłem zarówno git, jak i hg na własny użytek i zdecydowałem się na Hg. Czułem, że wygląda to na czystsze rozwiązanie i działało lepiej na większej liczbie platform w tym czasie. Ale to była głównie podrzucanie.

Ostatnio zacząłem używać git ze względu na git-svn i możliwość działania jako klient Subversion. To mnie przekonało i teraz całkowicie przerzuciłem się na git. Myślę, że ma nieco wyższą krzywą uczenia się( zwłaszcza jeśli trzeba grzebać w wnętrznościach), ale to naprawdę świetny system. Zamierzam przeczytać te dwa artykuły porównawcze, które John opublikował teraz.

Jestem obecnie w trakcie migracji z SVN do DVCS (podczas blogowania o moich odkryciach, mój pierwszy prawdziwy wysiłek blogowania...), i zrobiłem trochę badań (=googling). Z tego, co widzę, możesz zrobić większość rzeczy z obydwoma pakietami. Wygląda na to, że git ma kilka bardziej lub lepiej zaimplementowanych zaawansowanych funkcji, Wydaje mi się, że integracja z windows jest nieco lepsza dla mercuriala, z TortoiseHg. Wiem, że jest też Git Cheetah( próbowałem obu), ale rozwiązanie mercurial po prostu czuję się bardziej wytrzymała.

Widząc, że oba są open-source (prawda?) Nie sądzę, aby zabrakło też ważnych funkcji. Jeśli coś jest ważne, ludzie będą o to prosić, ludzie będą to kodować.

Myślę, że dla powszechnych praktyk, Git i Mercurial są więcej niż wystarczające. Obaj mają duże projekty, które ich używają( Git -> Linux kernel, Mercurial - > Mozilla foundation projects, oba oczywiście), więc nie sądzę, że tak naprawdę ich brakuje coś.

To powiedziawszy, jestem zainteresowany tym, co inni ludzie mówią na ten temat, ponieważ byłoby to świetne źródło dla moich wysiłków blogowania; -)

Istnieje wielki i wyczerpujący tabele porównawcze i wykresy na git, Mercurial i Bazaar w InfoQ ' s guide about DVCS.

Zdaję sobie sprawę, że nie jest to część odpowiedzi, ale w tej kwestii uważam również, że dostępność stabilnych wtyczek dla platform takich jak NetBeans i Eclipse odgrywa rolę w tym, które narzędzie jest lepiej dopasowane do zadania, a raczej, które narzędzie jest najlepiej dopasowane do "ciebie". To znaczy, chyba że naprawdę chcesz to zrobić w ten sposób.

Zarówno Eclipse (i wszystko na nim oparte), jak i NetBeans czasami mają problemy ze zdalnymi systemami plików (takimi jak SSH) i zewnętrznymi aktualizacjami plików; co jest jeszcze kolejny powód, dla którego chcesz, aby cokolwiek wybierzesz, działało "bezproblemowo".

Ja też staram się teraz odpowiedzieć na to pytanie .. i przygotowałem kandydatów na Git lub Mercurial .. dziękuję wszystkim za dostarczenie użytecznych informacji na ten temat, bez przechodzenia na religię.

Kolejne ciekawe porównanie mercurial i git: Mercurial vs Git. Główny nacisk kładzie się na wewnętrzne i ich wpływ na proces rozgałęziania.

Jeśli jesteś zainteresowany porównaniem wydajności Mercurial i Git, zajrzyj do tego artykułu . Wniosek jest następujący:

Git i Mercurial liczą się w dobrych liczbach, ale tworzą interesujący kompromis między szybkością a rozmiarem repozytorium. Mercurial jest szybki zarówno z dodaniem, jak i modyfikacją, i utrzymuje wzrost repozytorium pod kontrolą w tym samym czasie. Git jest również szybki, ale jego repozytorium rośnie bardzo szybko ze zmodyfikowanymi plikami, aż do przepakowania - a te przepakowania mogą bądź bardzo powolny. Ale spakowane repozytorium jest znacznie mniejsze niż Mercurial.

Strona mercurial zawiera świetny opis podobieństw i różnic między dwoma systemami, wyjaśniając różnice słownictwa i podstawowych pojęć. Jako długoletni użytkownik git, naprawdę pomógł mi zrozumieć Mercurial mentalność.

Jeśli migrujesz z SVN, użyj Mercurial, ponieważ jego składnia jest znacznie bardziej zrozumiała dla użytkowników SVN. Poza tym, z żadnym nie możesz się pomylić. Ale sprawdź Git tutorial i HGinit przed wyborem jednego z nich.

Ten link może pomóc ci zrozumieć różnicę http://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/

Niektórzy uważają, że systemy VCS muszą być skomplikowane. Zachęcają do wymyślania terminów i pojęć w terenie. Prawdopodobnie pomyślą, że liczne doktoraty na ten temat byłyby interesujące. Wśród nich są prawdopodobnie te, które zaprojektowały Gita.

Każde profesjonalne narzędzie musi być wyposażone w przejrzysty i intuicyjny CLI. Użytkownicy Mercurial mogą wykonać większość pracy, wydając proste polecenia bez żadnych dziwnych opcji. W Git double dash, szalone opcje są normą. Mercurial ma znaczną przewagę, jeśli jesteś osobą CLI(i szczerze mówiąc, każdy szanujący się inżynier oprogramowania powinien być).

Aby podać przykład, załóżmy, że popełniasz commit przez pomyłkę. Zapomniałeś edytować niektóre pliki. Aby cofnąć działanie w Mercurial wystarczy wpisać:

$ hg rollback

Otrzymasz komunikat, że system cofnie ostatnią transakcję.

W Git musisz wpisać:

$ git reset --soft HEAD^

Więc ok Załóżmy, że masz pojęcie o co chodzi z resetem. Ale dodatkowo musisz wiedzieć, czym są resety "-- soft " i " -- hard "(jakieś intuicyjne przypuszczenia?). No i oczywiście nie zapomnij na końcu znaku'^'! (teraz co w imieniu Ritchiego jest to...)

hg serve

I pozwól innym przeglądać twoje repozytorium.

Najważniejsze jest to, że Git robi to, co robi Mercurial, w znacznie bardziej skomplikowany sposób i ze znacznie gorszym CLI. Użyj Git, jeśli chcesz zmienić VCS twojego projektu w dziedzina naukowo-badawcza. Użyj Mercurial, jeśli chcesz wykonać pracę VCS bez przejmowania się nią i skupić się na prawdziwych zadaniach.