Używam gita od jakiegoś czasu w systemie Windows (z msysGit) i podoba mi się pomysł rozproszonej kontroli źródła. Niedawno patrzyłem na Mercurial (hg) i wygląda interesująco. Jednak nie mogę owinąć głowy wokół różnic między hg a git.
Czy ktoś porównał git i hg? Interesuje mnie to, co różni hg i git bez konieczności wchodzenia w dyskusję fanów.
Odpowiedzi:
Artykuły te mogą pomóc:
Edycja : Porównanie Git i Mercurial z celebrytami wydaje się być trendem. Oto jeszcze jeden:
Pracuję na Mercurial, ale zasadniczo uważam, że oba systemy są równoważne. Oba działają z tymi samymi abstrakcjami: serią migawek (zestawów zmian), które składają się na historię. Każdy zestaw zmian wie, skąd się wziął (nadrzędny zestaw zmian) i może mieć wiele podrzędnych zestawów zmian. Niedawne rozszerzenie hg-git zapewnia dwukierunkowy most między Mercurialem a Gitem i niejako pokazuje ten punkt.
Git kładzie duży nacisk na mutowanie tego wykresu historii (ze wszystkimi związanymi z tym konsekwencjami), podczas gdy Mercurial nie zachęca do przepisywania historii, ale i tak jest to łatwe, a konsekwencje takiego działania są dokładnie takie, jak należy się spodziewać (to znaczy , jeśli zmodyfikuję zestaw zmian, który już masz, twój klient zobaczy go jako nowy, jeśli ode mnie odciągniesz). Więc Mercurial ma uprzedzenia wobec nieniszczących poleceń.
Jeśli chodzi o lekkie oddziały, to Mercurial wspiera repozytoria z wieloma oddziałami od ..., zawsze myślę. Repozytoria Git z wieloma gałęziami są dokładnie tym: wiele rozbieżnych aspektów rozwoju w jednym repozytorium. Następnie Git dodaje nazwy do tych pasm i pozwala na zdalne zapytania o te nazwy. Zakładki rozszerzenie dla Mercurial dodaje nazwy lokalne, a także z Mercurial 1.6, można przenieść te zakładki wokół po naciśnięciu / pull ..
Używam Linuksa, ale najwyraźniej TortoiseHg jest szybszy i lepszy niż odpowiednik Git w systemie Windows (ze względu na lepsze wykorzystanie słabego systemu plików Windows). Zarówno http://github.com, jak i http://bitbucket.org zapewniają hosting online, usługa w Bitbucket jest świetna i responsywna (nie próbowałem github).
Wybrałem Mercurial, ponieważ wydaje się czysty i elegancki - zniechęciły mnie skrypty shell / Perl / Ruby, które dostałem z Git. Spróbuj zerknąć na git-instaweb.shplik, jeśli chcesz wiedzieć, co mam na myśli: jest to skrypt powłoki, który generuje skrypt Ruby , który, jak sądzę, uruchamia serwer WWW. Skrypt powłoki generuje kolejny skrypt powłoki, aby uruchomić pierwszy skrypt Ruby. Na wszelki wypadek jest też trochę Perla .
Podoba mi się post na blogu, który porównuje Mercurial i Git z Jamesem Bondem i MacGyverem - Mercurial jest w jakiś sposób bardziej cichy niż Git. Wydaje mi się, że ludzie korzystający z Mercurial nie są tak łatwo pod wrażeniem. Znajduje to odzwierciedlenie w sposobie, w jaki każdy system robi to, co Linus określił jako „najfajniejsze połączenie kiedykolwiek!” . W Git możesz łą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 wykonujemy:
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 --forceflaga do hg pull, która jest potrzebna, ponieważ Mercurial przerwie działanie, gdy wyciągniesz z niepowiązanego repozytorium. Takie różnice sprawiają, że Mercurial wydaje mi się bardziej elegancki.
git pull <url-of-project>. cytowana poczta pochodzi z pierwszych dni git (2005)
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 w przypadku aplikacji platformowych, jest bardziej złożona i ma ostrzejsze krawędzie niż aplikacje skoncentrowane. Ale oznacza to również, że VCS gita jest niezwykle elastyczny i istnieje ogromna głębia rzeczy bez kontroli źródła, które możesz zrobić z git.
To jest istota różnicy.
Git najlepiej rozumieć od podstaw - od formatu repozytorium do góry. Git Talk Scott Chacon jest doskonałym podkładem do tego. Jeśli spróbujesz użyć git, nie wiedząc, co dzieje się pod maską, w pewnym momencie skończysz zdezorientowany (chyba że będziesz trzymał się tylko bardzo podstawowej funkcjonalności). Może to zabrzmieć głupio, gdy wszystko, czego potrzebujesz, to DVCS do codziennej rutyny programowania, ale genialność git polega na tym, że format repozytorium jest w rzeczywistości bardzo prosty i dość łatwo można zrozumieć całą operację git.
Dla niektórych porównań bardziej technicznych, najlepszymi artykułami, które osobiście widziałem, są Dustin Sallings:
Właściwie używał obu DVCS i dobrze je rozumie - i ostatecznie wolał git.
Duża różnica dotyczy systemu Windows. Mercurial jest obsługiwany natywnie, Git nie. Możesz uzyskać bardzo podobny hosting do github.com z bitbucket.org (w rzeczywistości nawet lepiej, ponieważ otrzymujesz bezpłatne prywatne repozytorium). Przez jakiś czas korzystałem z msysGit, ale przeniosłem się do Mercurial i byłem z tego bardzo zadowolony.
Jeśli jesteś programistą systemu Windows i szukasz podstawowej kontroli odłączonej wersji, skorzystaj z Hg. Odkryłem, że Git jest niezrozumiały, podczas gdy Hg był prosty i dobrze zintegrowany z powłoką Windows. Pobrałem Hg i postępowałem zgodnie z tym samouczkiem (hginit.com) - dziesięć minut później miałem lokalne repozytorium i wróciłem do pracy nad moim projektem.
Myślę, że najlepszy opis „Mercurial vs. Git” to:
Są prawie identyczne. Najważniejsza różnica z mojego punktu widzenia (mam na myśli powód, dla którego wybrałem jeden DVCS zamiast drugiego), to sposób, w jaki oba programy zarządzają gałęziami.
Aby uruchomić nową gałąź, dzięki Mercurial, po prostu sklonuj repozytorium do innego katalogu i zacznij programować. Następnie ciągniesz i scalasz. W git musisz jawnie nadać nazwę nowej gałęzi tematu, której chcesz użyć, a następnie zacznij kodować przy użyciu tego samego katalogu .
Krótko mówiąc, każda gałąź Mercurial potrzebuje własnego katalogu; w git zwykle pracujesz w jednym katalogu. Zmiana gałęzi w Mercurial oznacza zmianę katalogów; w git oznacza proszenie git o zmianę zawartości katalogu za pomocą git checkout.
Jestem szczery: nie wiem, czy można zrobić to samo z Mercurialem, ale ponieważ zwykle pracuję nad projektami internetowymi, używanie zawsze tego samego katalogu z git wydaje mi się bardzo wygodne, ponieważ nie muszę ponownie -konfiguruj Apache i zrestartuj go, a nie bałaganię mojego systemu plików za każdym razem, gdy się rozgałęziam.
Edycja: Jak zauważył Deestan, Hg nazwał gałęzie , które można przechowywać w jednym repozytorium i pozwolić programistom na przełączanie gałęzi w tej samej kopii roboczej. gałęzie git nie są dokładnie takie same jak gałęzie nazwane Mercurial: są trwałe i nie wyrzucają gałęzi, jak w git. Oznacza to, że jeśli użyjesz nazwanego oddziału do zadań eksperymentalnych, nawet jeśli zdecydujesz się go nigdy nie łączyć, zostanie on zapisany w repozytorium. To jest powód, dla którego Hg zachęca do korzystania z klonów do eksperymentalnych, krótkoterminowych zadań i nazwanych gałęzi do długotrwałych zadań, takich jak gałęzie wydania.
Powód, dla którego wielu użytkowników Hg woli klony nad nazwaną gałęzią, jest o wiele bardziej społeczny lub kulturalny niż techniczny. Na przykład w ostatnich wersjach Hg można nawet zamknąć nazwaną gałąź i rekurencyjnie usunąć metadane z zestawów zmian.
Z drugiej strony git zaprasza do używania „nazwanych gałęzi”, które nie są trwałe i nie są przechowywane jako metadane na każdym zestawie zmian.
Z mojego osobistego punktu widzenia model gita jest zatem głęboko powiązany z koncepcją nazwanych gałęzi i przełączania się między gałęziami i innymi za pomocą tego samego katalogu; hg może zrobić to samo z nazwanymi gałęziami, ale zachęca to do korzystania z klonów, których osobiście nie lubię za bardzo.
Jest jedna ogromna różnica między gitem a rtęcią ; sposób, w jaki reprezentują każde zatwierdzenie. git reprezentuje zatwierdzenia jako migawki, a mercurial przedstawia je jako diffs.
Co to oznacza w praktyce? Cóż, wiele operacji jest szybszych w git, takich jak przełączanie na inne zatwierdzanie, porównywanie zatwierdzeń itp. Zwłaszcza jeśli te zatwierdzenia są daleko.
AFAIK nie ma przewagi podejścia rtęciowego.
Nic. Oba robią to samo, oba działają mniej więcej tak samo. Jedynym powodem, dla którego powinieneś wybrać jedno z drugiego, jest pomoc w projekcie, który już korzysta z jednego.
Innym możliwym powodem wyboru jednej jest aplikacja lub usługa, która obsługuje tylko jeden system. Na przykład, zdecydowałem się nauczyć git z powodu github ..
Również porównanie google (choć jest trochę stare, wykonane w 2008 roku)
Jeśli dobrze je rozumiem (i nie jestem ekspertem od każdego z nich), zasadniczo każda z nich ma inną filozofię. Po raz pierwszy użyłem rtęci przez 9 miesięcy. Teraz używam git dla 6.
hg to oprogramowanie do kontroli wersji. Jego głównym celem jest śledzenie wersji oprogramowania.
git to system plików oparty na czasie. Jego celem jest dodanie innego wymiaru do systemu plików. Większość ma pliki i foldery, git dodaje czasu. To, że akurat działa niesamowicie, ponieważ VCS jest produktem ubocznym jego projektu.
W Hg jest historia całego projektu, który zawsze stara się utrzymać. Domyślnie uważam, ż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 te pliki śledzenia (gałęzie / głowy), które określają, który zestaw tych obiektów reprezentuje drzewo plików w określonym stanie. Podczas pchania lub ciągnięcia git wysyła tylko obiekty potrzebne do poszczególnych gałęzi, które pchasz lub ciągniesz, co jest niewielkim podzbiorem wszystkich obiektów.
Jeśli chodzi o git, nie ma „1 projektu”. Możesz mieć 50 projektów w jednym repozytorium, a git nie będzie się tym przejmował. Każdy z nich może być zarządzany osobno w tym samym repozytorium i na żywo.
Koncepcja oddziałów Hg polega na odgałęzieniu głównego projektu lub odgałęzieniu itp. Git nie ma takiego pojęcia. Gałąź w git jest tylko stanem drzewa, wszystko jest gałęzią w git. Która gałąź jest oficjalna, aktualna lub najnowsza, nie ma znaczenia w git.
Nie wiem czy to miało jakiś sens. Gdybym mógł rysować, hg mógłby wyglądać tak, gdzie każdy zatwierdzenie jesto
o---o---o
/
o---o---o---o---o---o---o---o
\ /
o---o---o
Drzewo z jednym korzeniem i opadającymi z niego gałęziami. Chociaż git może to zrobić i często ludzie używają go w ten sposób, który nie jest egzekwowany. Zdjęcie git, jeśli istnieje coś takiego, może z łatwością wyglądać tak
o---o---o---o---o
o---o---o---o
\
o---o
o---o---o---o
W rzeczywistości pod pewnymi względami nie ma sensu pokazywanie gałęzi w git.
Jedna rzecz, która jest bardzo myląca dla dyskusji, zarówno git, jak i merkurial, mają coś, co nazywa się „gałęzią”, ale nie są to wcale te same rzeczy. Oddział mercurial powstaje, gdy występują konflikty między różnymi transakcjami repo. Oddział w git jest najwyraźniej podobny do klonu w hg. Ale klon, choć może dać podobne zachowanie, zdecydowanie nie jest taki sam. Zastanów się, czy wypróbowałem je w git vs hg przy użyciu dość dużego repozytorium chromu.
$ 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 za pomocą klonowania
$ 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ącymi przebiegami. To znaczy, uruchomiłem je dwa razy i to jest drugi bieg. klon hg jest tak samo jak git-new-workdir. Oba tworzą zupełnie nowy, działający katalog, prawie tak, jakbyś pisał na maszynie cp -r project project-clone. To nie to samo, co utworzenie nowej gałęzi w git. To o wiele większa waga. Jeśli istnieje prawdziwy odpowiednik rozgałęzienia gita w hg, nie wiem co to jest.
Rozumiem, że na pewnym poziomie hg i git mogą 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 utworzenie 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 o nazwie master. (Jestem pewien, że jest jakiś sposób, aby zrobić 1 linię zamiast 2)
Teraz do pracy nad jednym, który właśnie wykonuję
git checkout fix-game-save-bug
i zacznij działać. Zatwierdź rzeczy itp. Przełączanie między gałęziami nawet w projekcie tak dużym jak chrom jest niemal natychmiastowe. Właściwie nie wiem jak to zrobić w HG. To nie jest część samouczków, które przeczytałem.
Jeszcze jedna wielka różnica. Scena Gita.
Git ma pomysł na scenę. Możesz myśleć o tym jak o ukrytym folderze. Kiedy popełniasz, zatwierdzasz tylko to, co jest na scenie, a nie zmiany w działającym drzewie. To może brzmieć dziwnie. Jeśli chcesz zatwierdzić wszystkie zmiany w działającym drzewie, zrobiłbyś to, git commit -aco dodaje wszystkie zmodyfikowane pliki do stołu montażowego, a następnie je zatwierdza.
Jaki jest zatem sens etapu? Możesz łatwo rozdzielić swoje zobowiązania. Wyobraź sobie, że edytowałeś joypad.cpp i gamesave.cpp i chcesz zatwierdzić je 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 ma nawet polecenia, które decydują, które konkretne wiersze w tym samym pliku chcesz skopiować na scenę, abyś mógł oddzielnie rozdzielić te zatwierdzenia. Dlaczego chcesz to zrobić? Ponieważ jako osobne zatwierdzenia inni mogą wyciągać tylko te, których chcą, lub jeśli wystąpił problem, mogą cofnąć tylko zatwierdzenie, które miało problem.
git add --patchpatrz linux.die.net/man/1/git-add lub użyj git add -i, jak w stackoverflow.com/questions/2372583/…
checkout -b <name>możesz po prostu git branch <name>utworzyć nowy oddział bez przełączania się na niego
Na blogu versioncontrolblog znajduje się dynamiczna tabela porównawcza, na której można porównać kilka różnych systemów kontroli wersji.
dir-a/foo.c, aby dir-b/foo.ci nadal pracować na dir-b/foo.c, wówczas prace nad dir-a/foo.cbędą prawidłowo połączył się z moją pracą po pull.
Istnieją dość znaczące różnice, jeśli chodzi o pracę z oddziałami (szczególnie krótkoterminowymi).
Wyjaśniono to w tym artykule (BranchingExplained), który porównuje Mercurial z Git.
Czy w twoim projekcie są współpracownicy z systemem Windows?
Ponieważ jeśli tak, GUI dla systemu Windows wydaje się niezręczny, trudny i nieprzyjazny.
Natomiast Mercurial-on-Windows nie jest żadnym problemem.
W zeszłym roku oceniłem git i hg na własne potrzeby i zdecydowałem się na hg. Czułem, że to wygląda na czystsze rozwiązanie i działało wówczas lepiej na większej liczbie platform. Było to jednak głównie podrzucenie.
Ostatnio zacząłem używać git z powodu git-svn i zdolności do działania jako klient Subversion. To mnie przekonało i teraz całkowicie zmieniłem na git. Wydaje mi się, że ma nieco wyższą krzywą uczenia się (szczególnie jeśli musisz szturchać wnętrze), ale to naprawdę świetny system. Przeczytam te dwa artykuły porównawcze, które John opublikował teraz.
Obecnie jestem w trakcie migracji z SVN do DVCS (podczas blogowania o moich odkryciach, moim pierwszym prawdziwym wysiłku blogowania ...), i przeprowadziłem trochę badań (= google). O ile widzę, możesz zrobić większość rzeczy za pomocą obu pakietów. 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 mercurial, z TortoiseHg. Wiem, że jest też Git Cheetah (próbowałem obu), ale rozwiązanie rtęciowe wydaje się bardziej niezawodne.
Widząc, że oba są open-source (prawda?), Nie sądzę, że w żadnym z nich nie zabraknie ważnych funkcji. Jeśli coś jest ważne, ludzie będą o to prosić, ludzie to kodują.
Myślę, że w przypadku powszechnych praktyk Git i Mercurial są więcej niż wystarczające. Obaj mają duże projekty, które ich używają (projekty Git -> jądro linuksa, Mercurial -> Mozilla Foundation, oba oczywiście oczywiście), więc nie sądzę, żeby w żadnym z nich czegoś brakowało.
Biorąc to pod uwagę, jestem zainteresowany tym, co mówią o tym inni ludzie, ponieważ byłoby to świetnym źródłem moich blogów ;-)
Świetne i wyczerpujące tabele porównawcze i wykresy na temat git, Mercurial i Bazaar znajdują się w przewodniku InfoQ o DVCS .
Zdaję sobie sprawę, że to nie jest część odpowiedzi, ale w tej kwestii myślę również, że dostępność stabilnych wtyczek dla platform takich jak NetBeans i Eclipse odgrywa rolę, w której narzędzie lepiej pasuje do zadania, a raczej które narzędzie najlepiej pasuje do „ciebie”. To znaczy, chyba że naprawdę chcesz to zrobić w sposób CLI.
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 kolejnym powodem, dla którego chcesz, aby wszystko, co wybierzesz, działało „płynnie”.
Próbuję teraz odpowiedzieć sobie na to pytanie… i przygotowałem kandydatów do Git lub Mercurial .. dziękuję wszystkim za udzielenie użytecznych informacji na ten temat bez konieczności zakonników.
Kolejne interesujące porównanie rtęci i git: Mercurial vs Git . Główny nacisk kładziony jest na elementy wewnętrzne i ich wpływ na proces rozgałęziania.
Jeśli jesteś zainteresowany porównaniem wydajności Mercurial i Git, zapoznaj się z tym artykułem . Z tego wniosek:
Git i Mercurial obracają się w dobrych liczbach, ale stanowią interesujący kompromis między szybkością a rozmiarem repozytorium. Mercurial jest szybki, zarówno z dodawaniem, jak i modyfikacjami, i jednocześnie kontroluje wzrost repozytorium. Git jest również szybki, ale jego repozytorium rośnie bardzo szybko ze zmodyfikowanymi plikami, aż do ponownego spakowania - a te przepakowania mogą być bardzo wolne. Ale zapakowane repozytorium jest znacznie mniejsze niż Mercurial.
Witryna rtęciowa zawiera doskonały opis podobieństw i różnic między dwoma systemami, wyjaśniając różnice w słownictwie i podstawowych pojęciach. Jako długoletni użytkownik git naprawdę pomógł mi zrozumieć sposób myślenia Mercurial.
Jeśli przeprowadzasz migrację z SVN, użyj Mercurial, ponieważ jego składnia jest DUŻO bardziej zrozumiała dla użytkowników SVN. Poza tym nie możesz się pomylić z żadnym z nich. Ale sprawdź samouczek GIT i HGinit przed wybraniem 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 koncepcji w terenie. Prawdopodobnie pomyśleliby, że liczne doktoraty na ten temat byłyby interesujące. Wśród nich są prawdopodobnie ci, którzy zaprojektowali Git.
Mercurial został zaprojektowany z inną mentalnością. Deweloperzy nie powinni bardzo przejmować się VCS i powinni zamiast tego poświęcić czas na swoją główną funkcję: inżynierię oprogramowania. Mercurial pozwala użytkownikom korzystać z systemu i szczęśliwie nadużywać go, nie dopuszczając do błędów, których nie można odzyskać.
Każde profesjonalne narzędzie musi mieć jasno zaprojektowany i intuicyjny interfejs użytkownika. 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 dać przykład, załóżmy, że popełniłeś błąd przez pomyłkę. Zapomniałeś edytować niektórych plików. Aby cofnąć akcję w Mercurial, wystarczy wpisać:
$ hg rollback
Następnie pojawi się komunikat, że system cofnął ostatnią transakcję.
W Git musisz wpisać:
$ git reset --soft HEAD^
Więc ok, przypuśćmy, że masz pojęcie, na czym polega reset. Ale dodatkowo musisz wiedzieć, jakie są resetowania „--soft” i „--hard” (jakieś intuicyjne domysły?). No i oczywiście nie zapomnij na końcu znaku „^”! (teraz, co na imię Ritchie to ...)
Integracja Mercurial z narzędziami innych firm, takimi jak kdiff3 i meld, jest również znacznie lepsza. Wygeneruj swoje łatki, łącz swoje gałęzie bez większego zamieszania. Mercurial zawiera również prosty serwer HTTP, który aktywujesz przez wpisanie
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 przy znacznie gorszym CLI. Użyj Git, jeśli chcesz przekształcić VCS swojego projektu w dziedzinę badań naukowych. Użyj Mercurial, jeśli chcesz wykonać zadanie VCS, nie troszcząc się o to, i skup się na swoich prawdziwych zadaniach.