Qual è la differenza tra Mercurial e Git?

StackOverflow https://stackoverflow.com/questions/35837

Domanda

Utilizzo git da qualche tempo su Windows (con msysGit) e mi piace l'idea del controllo del codice sorgente distribuito.Proprio di recente ho guardato Mercurial (hg) e sembra interessante.Tuttavia, non riesco a capire le differenze tra hg e git.

Qualcuno ha fatto un confronto fianco a fianco tra git e hg?Sono interessato a sapere cosa differenzia hg e git senza dover entrare in una discussione da fanboy.

È stato utile?

Soluzione

Questi articoli possono aiutare:

Modificare:Paragonare Git e Mercurial alle celebrità sembra essere una tendenza.Eccone un altro:

Altri suggerimenti

Lavoro su Mercurial, ma fondamentalmente credo che entrambi i sistemi siano equivalenti.Entrambi lavorano con le stesse astrazioni:una serie di istantanee (changeset) che costituiscono la cronologia.Ogni changeset sa da dove proviene (il changeset genitore) e può avere molti changeset figli.Il recente accidenti extension fornisce un ponte a doppio senso tra Mercurial e Git e in un certo senso mostra questo punto.

Git si concentra fortemente sulla mutazione di questo grafico storico (con tutte le conseguenze che ciò comporta), mentre Mercurial non incoraggia la riscrittura della storia, ma è comunque facile da fare e le conseguenze di ciò sono esattamente quelle che dovresti aspettarti che siano (vale a dire, se modifico un changeset che hai già, il tuo cliente lo vedrà come nuovo se lo estrai da me).Quindi Mercurial ha un pregiudizio verso comandi non distruttivi.

Per quanto riguarda i rami leggeri, Mercurial ha supportato i repository con più rami poiché..., penso sempre.I repository Git con più rami sono esattamente questo:molteplici filoni di sviluppo divergenti in un unico repository.Git quindi aggiunge nomi a questi elementi e ti consente di interrogare questi nomi in remoto.IL Segnalibri l'estensione per Mercurial aggiunge nomi locali e con Mercurial 1.6 puoi spostare questi segnalibri quando spingi/tiri..

Uso Linux, ma a quanto pare TortoiseHg è più veloce e migliore dell'equivalente Git su Windows (grazie al migliore utilizzo del povero filesystem di Windows).Entrambi http://github.com E http://bitbucket.org fornire hosting online, il servizio di Bitbucket è ottimo e reattivo (non ho provato github).

Ho scelto Mercurial perché sembra pulito ed elegante: sono rimasto scoraggiato dagli script Shell/Perl/Ruby che ho ricevuto con Git.Prova a dare un'occhiata al git-instaweb.sh file se vuoi sapere cosa intendo:è un conchiglia script che genera un file Rubino script, che penso esegua un server web.Lo script di shell genera un altro script di shell per avviare il primo script Ruby.C'è anche un po' di Perl, per buona misura.

mi piace il post sul blog che mette a confronto Mercurial e Git con James Bond e MacGyver: Mercurial è in qualche modo più discreto di Git.Mi sembra che le persone che usano Mercurial non si impressionino così facilmente.Ciò si riflette nel modo in cui ciascun sistema esegue ciò che Linus ha descritto "la fusione più bella di SEMPRE!".In Git puoi unirti a un repository non correlato facendo:

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

Quei comandi sembrano piuttosto arcani ai miei occhi.In Mercurial facciamo:

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

Nota come i comandi Mercurial siano semplici e per niente speciali: l'unica cosa insolita è il --force bandiera a hg pull, che è necessario poiché altrimenti Mercurial si interromperà quando esegui il pull da un repository non correlato.Sono differenze come questa che mi fanno sembrare Mercurial più elegante.

Git è una piattaforma, Mercurial è “solo” un’applicazione.Git è una piattaforma di filesystem con versione che viene fornita con un'app DVCS nella confezione, ma come normale per le app della piattaforma, è più complessa e ha bordi più ruvidi rispetto alle app mirate.Ma questo significa anche che il VCS di git è immensamente flessibile, e c’è un’enorme quantità di cose non legate al controllo del codice sorgente che puoi fare con git.

Questa è l'essenza della differenza.

Git è meglio compreso da zero, dal formato del repository in su. Git Talk di Scott Chacon è un ottimo primer per questo.Se provi a utilizzare git senza sapere cosa sta succedendo dietro le quinte, prima o poi rimarrai confuso (a meno che non ti attieni solo alle funzionalità di base).Questo può sembrare stupido quando tutto ciò che desideri è un DVCS per la tua routine di programmazione quotidiana, ma la genialità di git è che il formato del repository è in realtà molto semplice e tu Potere comprendere abbastanza facilmente l’intera operazione di Git.

Per alcuni confronti più orientati alla tecnicità, i migliori articoli che ho visto personalmente sono quelli di Dustin Sallings:

In realtà ha utilizzato ampiamente entrambi i DVCS e li comprende entrambi bene, finendo per preferire git.

La grande differenza è su Windows.Mercurial è supportato nativamente, Git no.Puoi ottenere un hosting molto simile a github.com con bitbucket.org (in realtà è ancora meglio se ottieni un repository privato gratuito).Ho usato msysGit per un po', ma poi sono passato a Mercurial e ne sono rimasto molto soddisfatto.

Se sei uno sviluppatore Windows alla ricerca di un controllo di revisione disconnesso di base, scegli Hg.Ho trovato Git incomprensibile mentre Hg era semplice e ben integrato con la shell di Windows.Ho scaricato Hg e l'ho seguito questo tutorial (hginit.com) - dieci minuti dopo avevo un repository locale e tornavo a lavorare sul mio progetto.

Penso che la migliore descrizione di "Mercurial vs.Git" è:

"Git è Wesley Snipes.Mercurial è Denzel Washington"

Sono quasi identici.La differenza più importante, dal mio punto di vista (voglio dire, il motivo che mi ha portato a scegliere un DVCS piuttosto che un altro) è il modo in cui i due programmi gestiscono i rami.

Per avviare un nuovo ramo, con Mercurial, basta clonare il repository in un'altra directory e iniziare a sviluppare.Quindi, tiri e unisci.Con git, devi dare esplicitamente un nome al nuovo ramo dell'argomento che desideri utilizzare, quindi inizi a scrivere il codice utilizzando la stessa directory.

In breve, ogni ramo di Mercurial necessita della propria directory;in Git di solito lavori su una singola directory.Cambiare ramo in Mercurial significa cambiare directory;in git, significa chiedere a git di modificare il contenuto della directory con git checkout.

Sono onesto:Non so se sia possibile fare lo stesso con Mercurial, ma dato che di solito lavoro su progetti web, usare sempre la stessa directory con git mi sembra molto comodo, dato che non devo riconfigurare Apache e riavviare e non rovino il mio filesystem ogni volta che eseguo il branch.

Modificare:Come ha notato Deestan, Hg ha rami nominati, che può essere archiviato in un unico repository e consente allo sviluppatore di cambiare ramo all'interno della stessa copia di lavoro.In ogni caso, i rami git non sono esattamente gli stessi dei rami con nome Mercurial:sono permanenti e non buttano via i rami, come in Git.Ciò significa che se utilizzi un ramo con nome per attività sperimentali, anche se decidi di non unirlo mai, verrà archiviato nel repository.Questo è il motivo per cui Hg incoraggia a utilizzare i cloni per attività sperimentali di breve durata e rami con nome per attività di lunga esecuzione, come per i rami di rilascio.

Il motivo per cui molti utenti di Hg preferiscono i cloni rispetto al ramo con nome è molto più sociale o culturale che tecnico.Ad esempio, con le ultime versioni di Hg, è persino possibile chiudere un ramo con nome e rimuovere ricorsivamente i metadati dai changeset.

D'altro canto, git invita a utilizzare "rami denominati" che non sono permanenti e non vengono archiviati come metadati su ciascun changeset.

Dal mio punto di vista personale, quindi, il modello di git è profondamente legato al concetto di rami con nome e di passaggio da un ramo all'altro all'interno della stessa directory;hg può fare lo stesso con i rami con nome, ma incoraggia comunque l'uso dei cloni, cosa che personalmente non mi piace molto.

Ce n'è uno Enorme differenza fra idiota E mercuriale;il modo in cui rappresentano ciascun commit. idiota rappresenta i commit come istantanee, mentre mercuriale li rappresenta come differenze.

Cosa significa questo in pratica?Bene, molte operazioni sono più veloci in Git, come passare a un altro commit, confrontare commit, ecc.Soprattutto se questi impegni sono lontani.

Per quanto ne so, non c'è alcun vantaggio nell'approccio di Mercurial.

Niente.Entrambi fanno la stessa cosa, entrambi si comportano allo stesso modo.L'unico motivo per cui dovresti sceglierne uno rispetto all'altro è se aiuti con un progetto che ne utilizza già uno.

L'altro possibile motivo per sceglierne uno è un'applicazione o un servizio che supporta solo uno dei sistemi.Ad esempio, ho praticamente scelto di imparare git a causa di github..

Anche il confronto di Google (anche se è un po' vecchio, fatto nel 2008)

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

Se li capisco bene (e sono ben lungi dall'essere un esperto di ciascuno) fondamentalmente hanno ciascuno una filosofia diversa.Ho usato Mercurial per la prima volta per 9 mesi.Ora ho usato git per 6.

hg è un software di controllo della versione.Il suo obiettivo principale è tenere traccia delle versioni di un software.

git è un file system basato sul tempo.Il suo obiettivo è aggiungere un'altra dimensione a un file system.La maggior parte ha file e cartelle, git aggiunge tempo.Il fatto che funzioni alla grande come VCS è un sottoprodotto del suo design.

In hg c'è la cronologia dell'intero progetto che cerca sempre di mantenere.Per impostazione predefinita, credo che hg voglia tutte le modifiche a tutti gli oggetti da parte di tutti gli utenti quando spingono e tirano.

In git c'è solo un pool di oggetti e questi file di tracciamento (rami/teste) che determinano quale insieme di questi oggetti rappresenta l'albero di file in un particolare stato.Quando spingi o tiri, git invia solo gli oggetti necessari per i rami particolari che stai spingendo o tirando, che è un piccolo sottoinsieme di tutti gli oggetti.

Per quanto riguarda Git non esiste un "1 progetto".Potresti avere 50 progetti tutti nello stesso repository e a Git non importerebbe.Ognuno potrebbe essere gestito separatamente nello stesso repository e vivere bene.

Il concetto di rami di Hg è quello di diramarsi dal progetto principale o di diramarsi da rami ecc.Git non ha un concetto del genere.Un ramo in Git è solo uno stato dell'albero, tutto è un ramo in Git.Quale ramo sia ufficiale, attuale o più recente non ha significato in Git.

Non so se avesse senso.Se potessi disegnare immagini, hg potrebbe assomigliare a questo dove ogni commit è a o

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

Un albero con una sola radice e rami che si staccano da essa.Sebbene Git possa farlo e spesso le persone lo usano in questo modo, ciò non viene applicato.Un'immagine git, se esiste una cosa del genere, potrebbe facilmente assomigliare a questa

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

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

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

In effetti per certi versi non ha nemmeno senso mostrare i rami in git.

Una cosa che crea molta confusione nella discussione, git e mercurial hanno entrambi qualcosa chiamato "ramo" ma non sono neanche lontanamente la stessa cosa.Un ramo in mercurial si verifica quando ci sono conflitti tra diversi repository.Un ramo in git è apparentemente simile a un clone in hg.Ma un clone, anche se potrebbe dare un comportamento simile, sicuramente non è la stessa cosa.Considera di provarli in git vs hg usando il repository chromium che è piuttosto grande.

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

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

E ora in hg usando clone

$ 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

Entrambi sono percorsi caldi.Cioè, li ho eseguiti due volte e questa è la seconda esecuzione.hg clone è in realtà uguale a git-new-workdir.Entrambi creano una directory di lavoro completamente nuova quasi come se l'avessi digitata cp -r project project-clone.Non è la stessa cosa che creare un nuovo ramo in Git.È molto più pesante.Se esiste un vero equivalente della ramificazione di Git in hg, non so cosa sia.

Capisco a un certo livello hg e git Potrebbe poter fare cose simili.Se è così, allora c'è ancora un'enorme differenza nel flusso di lavoro a cui ti portano.In Git, il flusso di lavoro tipico è creare un ramo per ogni funzionalità. 

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

Ciò ha appena creato 3 rami, ciascuno basato su un ramo chiamato master.(Sono sicuro che ci sia un modo in Git per creare quelle 1 riga ciascuna invece di 2)

Ora per lavorarci su uno lo faccio e basta

git checkout fix-game-save-bug

e iniziare a lavorare.Impegnare cose, ecc.Il passaggio da un ramo all'altro, anche in un progetto grande come Chrome, è quasi istantaneo.In realtà non so come farlo in hg.Non fa parte di nessun tutorial che ho letto.

Un'altra grande differenza.La fase di Git.

Git ha questa idea di palcoscenico.Puoi considerarla come una cartella nascosta.Quando esegui il commit, impegni solo ciò che è sullo stage, non le modifiche nel tuo albero di lavoro.Potrebbe sembrare strano.Se vuoi impegnare tutte le modifiche nel tuo albero di lavoro, lo faresti git commit -a che aggiunge tutti i file modificati allo stage e poi li esegue il commit.

Che senso ha allora il palco?Puoi facilmente separare i tuoi commit.Immagina di aver modificato joypad.cpp e gamesave.cpp e di volerli impegnare separatamente

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 ha anche comandi per decidere quali righe particolari nello stesso file vuoi copiare sullo stage in modo da poter dividere anche questi commit separatamente.Perché vorresti farlo?Perché come commit separati gli altri possono estrarre solo quelli che desiderano o se si è verificato un problema possono annullare solo il commit che presentava il problema.

C'è una tabella di confronto dinamica sul blog versioncontrol dove puoi confrontare diversi sistemi di controllo della versione.

Ecco una tabella comparativa tra git, hg e bzr.

Ci sono differenze piuttosto significative quando si tratta di lavorare con le filiali (soprattutto quelle a breve termine).

È spiegato in questo articolo (BranchingExplained) che confronta Mercurial con Git.

Ci sono collaboratori basati su Windows nel tuo progetto?

Perché se ci sono, la GUI di Git per Windows sembra scomoda, difficile, ostile.

Mercurial su Windows, al contrario, è un gioco da ragazzi.

Una cosa da notare tra mercurial di bitbucket.org e git di github è che mercurial può avere tutti i repository privati ​​che desideri, ma github devi passare a un account a pagamento.Quindi, ecco perché scelgo bitbucket che utilizza mercurial.

L'anno scorso ho valutato sia git che hg per uso personale e ho deciso di utilizzare hg.Mi sembrava una soluzione più pulita e all'epoca funzionava meglio su più piattaforme.Si è trattato soprattutto di un errore, però.

Più recentemente, ho iniziato a utilizzare git grazie a git-svn e alla capacità di agire come client Subversion.Questo mi ha conquistato e ora sono passato completamente a Git.Penso che abbia una curva di apprendimento leggermente più alta (soprattutto se hai bisogno di curiosare all'interno), ma è davvero un ottimo sistema.Vado a leggere i due articoli comparativi che John ha pubblicato adesso.

Attualmente sto migrando da SVN a DVCS (mentre scrivo sul blog le mie scoperte, il mio primo vero tentativo di bloggare...), e ho fatto un po' di ricerca (=cercando su Google).Per quanto posso vedere puoi fare la maggior parte delle cose con entrambi i pacchetti.Sembra che Git abbia alcune funzionalità avanzate più o meglio implementate, sento che l'integrazione con Windows sia un po 'migliore per Mercurial, con Tortoisehg.So che c'è anche Git Cheetah (li ho provati entrambi), ma la soluzione mercuriale sembra semplicemente più robusta.

Visto che sono entrambi open source (giusto?), non credo che a nessuno dei due mancheranno funzionalità importanti.Se qualcosa è importante, le persone lo chiederanno, lo codificheranno.

Penso che per le pratiche comuni Git e Mercurial siano più che sufficienti.Entrambi hanno grandi progetti che li utilizzano (Git -> kernel Linux, Mercurial -> progetti Mozilla Foundation, entrambi tra gli altri ovviamente), quindi non penso che a nessuno dei due manchi davvero qualcosa.

Detto questo, sono interessato a cosa dicono gli altri a riguardo, poiché sarebbe un'ottima fonte per i miei sforzi di blogging ;-)

C'è un ottimo ed esaustivo confronto di tabelle e grafici su Git, Mercurial e Bazaar su La guida di InfoQ sul DVCS.

Mi rendo conto che questa non fa parte della risposta, ma a questo proposito, penso anche che la disponibilità di plugin stabili per piattaforme come NetBeans ed Eclipse svolga un ruolo nel determinare quale strumento è più adatto all'attività, o meglio, quale strumento è la soluzione migliore per "te".Cioè, a meno che tu Veramente voglio farlo in modo CLI.

Sia Eclipse (e tutto ciò che si basa su di esso) che NetBeans a volte hanno problemi con file system remoti (come SSH) e aggiornamenti esterni di file;che è ancora un altro motivo per cui vuoi che qualunque cosa tu scelga funzioni "perfettamente".

Sto cercando di rispondere anch'io a questa domanda in questo momento..e ho ridotto i candidati a Git o Mercurial..grazie a tutti per aver fornito input utili su questo argomento senza diventare religiosi.

Ancora un altro interessante confronto tra mercurial e git: Mercurial contro Git.L'attenzione principale è rivolta agli interni e alla loro influenza sul processo di ramificazione.

Se sei interessato a un confronto delle prestazioni di Mercurial e Git, dai un'occhiata a Questo articolo.La conclusione è:

Git e Mercurial ottengono entrambi buoni numeri, ma creano un interessante compromesso tra velocità e dimensioni del repository.Mercurial è veloce sia con le aggiunte che con le modifiche e allo stesso tempo mantiene sotto controllo la crescita del repository.Anche Git è veloce, ma il suo repository cresce molto rapidamente con i file modificati fino al repack, e questi repack possono essere molto lenti.Ma il repository compresso è molto più piccolo di quello di Mercurial.

Il sito web Mercurial ha un file ottima descrizione delle somiglianze e delle differenze tra i due sistemi, spiegando le differenze di vocabolario e di concetti sottostanti.Essendo un utente Git da molto tempo, mi ha davvero aiutato a comprendere la mentalità di Mercurial.

Se stai migrando da SVN, usa Mercurial poiché la sua sintassi è MOLTO più comprensibile per gli utenti SVN.A parte questo, non puoi sbagliare con nessuno dei due.Ma controlla Esercitazione GIT E HGinit prima di selezionarne uno.

Questo collegamento può aiutarti a capire la differenzahttp://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/

Alcune persone pensano che i sistemi VCS debbano essere complicati.Incoraggiano a inventare termini e concetti sul campo.Probabilmente penserebbero che numerosi dottorati di ricerca sull'argomento sarebbero interessanti.Tra questi ci sono probabilmente quelli che hanno progettato Git.

Mercurial è progettato con una mentalità diversa.Gli sviluppatori non dovrebbero preoccuparsi molto di VCS e dovrebbero invece dedicare il loro tempo alla loro funzione principale:Ingegneria software.Mercurial consente agli utenti di utilizzare e abusare felicemente del sistema senza consentire loro di commettere errori irrecuperabili.

Qualsiasi strumento professionale deve essere dotato di una CLI chiara e intuitiva.Gli utenti Mercurial possono svolgere la maggior parte del lavoro emettendo semplici comandi senza strane opzioni.In Git double dash, le opzioni folli sono la norma.Mercurial ha un vantaggio sostanziale se sei un utente CLI (e, a dire il vero, ogni ingegnere del software che si rispetti dovrebbe esserlo).

Per fare un esempio, supponiamo di eseguire un commit per errore.Hai dimenticato di modificare alcuni file.Per annullare la tua azione in Mercurial digita semplicemente:

$ hg rollback

Riceverai quindi un messaggio che informa che il sistema annulla la tua ultima transazione.

In Git devi digitare:

$ git reset --soft HEAD^

Quindi ok, supponiamo che tu abbia un'idea di cosa significhi il ripristino.Ma in più devi sapere cosa sono i ripristini "--soft" e "--hard" (qualche ipotesi intuitiva?).Oh, e ovviamente non dimenticare il carattere '^' alla fine!(ora, in nome di Ritchie, cosa è quello...)

Anche l'integrazione di Mercurial con strumenti di terze parti come kdiff3 e meld è molto migliore.Genera le tue patch e unisci i tuoi rami senza troppi problemi.Mercurial include anche un semplice server http che puoi attivare digitando

hg serve

E consenti agli altri di sfogliare il tuo repository.

La conclusione è che Git fa quello che fa Mercurial, in un modo molto più complicato e con una CLI di gran lunga inferiore.Usa Git se vuoi trasformare il VCS del tuo progetto in un campo di ricerca scientifica.Usa Mercurial se vuoi portare a termine il lavoro VCS senza preoccuparti troppo e concentrarti sui tuoi compiti reali.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top