tag - mercurial vs git




Qual è la differenza tra Mercurial e Git? (17)

A volte l'anno scorso ho valutato sia git che hg per il mio uso personale e ho deciso di andare con hg. Ho sentito che sembrava una soluzione più pulita, e ha funzionato meglio su più piattaforme in quel momento. Era per lo più un sballottamento, però.

Più recentemente, ho iniziato a usare git a causa di git-svn e la capacità di agire come client di Subversion. Questo mi ha conquistato e ora sono passato completamente al git. Penso che abbia una curva di apprendimento leggermente più alta (specialmente se hai bisogno di sondare l'interno), ma è davvero un ottimo sistema. Vado a leggere questi due articoli di comparazione pubblicati da John.

Sto usando git da un po 'di 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 comprendere le differenze tra hg e git.

Qualcuno ha fatto un confronto side-by-side tra git e hg? Sono interessato a sapere cosa differisce da hg e git senza dover saltare in una discussione fanboy.


Alcune persone pensano che i sistemi VCS debbano essere complicati. Incoraggiano a inventare termini e concetti sul campo. Probabilmente penserebbero che numerosi dottorati sull'argomento sarebbero interessanti. Tra quelli 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: l'ingegneria del software. Mercurial consente agli utenti di utilizzare e felicemente abusare del sistema senza che possano commettere errori irreparabili.

Qualsiasi strumento professionale deve avere una CLI chiaramente progettata e intuitiva. Gli utenti Mercurial possono eseguire la maggior parte del lavoro emettendo semplici comandi senza opzioni strane. In Git double dash, le opzioni pazze sono la norma. Mercurial ha un vantaggio sostanziale se sei una persona CLI (e per essere onesto, qualsiasi ingegnere del software che si rispetti dovrebbe essere).

Per fare un esempio, supponiamo di fare un commit per errore. Hai dimenticato di modificare alcuni file. Per annullare l'azione in Mercurial devi semplicemente digitare:

$ hg rollback

Si ottiene quindi un messaggio che il sistema annulla la tua ultima transazione.

In Git devi digitare:

$ git reset --soft HEAD^

Ok, supponiamo che tu abbia un'idea di cosa sia il reset. Ma in più devi sapere quali sono le reimpostazioni "--soft" e "--hard" (qualche ipotesi intuitiva?). Oh e, naturalmente, non dimenticare il carattere '^' alla fine! (ora cosa nel nome di Ritchie è ...)

Anche l'integrazione di Mercurial con strumenti di terze parti come kdiff3 e meld è molto meglio. Genera le tue toppe unisci i tuoi rami senza tante storie. Mercurial include anche un semplice server http che si attiva digitando

hg serve

E lascia che gli altri sfogliano il tuo repository.

La linea di fondo è, Git fa quello che fa Mercurial, in un modo molto più complicato e con una CLI molto inferiore. Usa Git se vuoi trasformare il VCS del tuo progetto in un campo di ricerca scientifica. Utilizzare Mercurial se si desidera eseguire il lavoro VCS senza preoccuparsi troppo e concentrarsi sulle proprie attività reali.


Ancora un altro interessante confronto tra mercurial e git: Mercurial vs Git . L'attenzione principale è sugli interni e sulla loro influenza sul processo di ramificazione.


C'è un'enorme differenza tra git e mercurial ; il modo in cui rappresentano ogni commit. git rappresenta commit come istantanee, mentre mercurial li rappresenta come diff.

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

AFAIK non ha alcun vantaggio dell'approccio di Mercurial.


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

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



Git è una piattaforma, Mercurial è "solo" un'applicazione. Git è una piattaforma di file system con versione che viene fornita con un'app DVCS nella scatola, ma come di consueto per le app di piattaforma, è più complessa e presenta margini più ruvidi rispetto alle app focalizzate. Ma questo significa anche che il VCS di Git è estremamente flessibile, e c'è un'enorme profondità di cose che non puoi controllare con la sorgente che puoi fare con git.

Questa è l'essenza della differenza.

Git è meglio capito da zero - dal formato repository up. Il Git Talk di Scott Chacon è un ottimo primer per questo. Se provi ad usare git senza sapere cosa sta succedendo sotto il cofano, finirai per essere confuso ad un certo punto (a meno che non ti attacchi solo a funzionalità di base). Questo può sembrare stupido quando tutto ciò che desideri è un DVCS per la tua routine di programmazione quotidiana, ma il genio di git è che il formato del repository è in realtà molto semplice e puoi capire l'intera operazione di git abbastanza facilmente.

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

In realtà ha usato entrambi i DVCS in modo esteso e li comprende entrambi bene e ha finito per preferire il git.



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 storia. Ogni changeset sa da dove proviene (il changeset genitore) e può avere molti changeset figli. La recente estensione di hg-git fornisce un ponte a due vie tra Mercurial e Git e mostra questo punto.

Git si concentra molto sulla modifica di questo grafico storico (con tutte le conseguenze che ne derivano) mentre Mercurial non incoraggia la riscrittura della storia, ma è comunque facile da fare e le conseguenze di ciò sono esattamente ciò che dovresti aspettarti che siano (cioè , se modifico un changeset che hai già, il tuo client lo vedrà come nuovo se mi tiri fuori). Quindi Mercurial ha un pregiudizio verso i comandi non distruttivi.

Per quanto riguarda i rami leggeri, Mercurial ha supportato i repository con più rami da quando ..., penso sempre. I repository Git con più filiali sono esattamente questo: più gruppi di sviluppo divergenti in un singolo repository. Git quindi aggiunge nomi a questi filamenti e consente di interrogare questi nomi in remoto. L'estensione Bookmarks per Mercurial aggiunge nomi locali e con Mercurial 1.6 puoi spostare questi segnalibri quando premi / tira ..

Io uso Linux, ma a quanto pare TortoiseHg è più veloce e migliore dell'equivalente Git su Windows (grazie a un migliore utilizzo del povero filesystem di Windows). Sia http://github.com che http://bitbucket.org offrono hosting online, il servizio di Bitbucket è ottimo e reattivo (non ho provato Github).

Ho scelto Mercurial perché è pulito ed elegante - Sono stato scoraggiato dagli script shell / Perl / Ruby che ho ricevuto con Git. Prova a dare un'occhiata al file git-instaweb.sh se vuoi sapere cosa intendo: si tratta di uno script di shell che genera uno script Ruby , che a mio avviso gestisce un server web. Lo script di shell genera un altro script di shell per avviare il primo script di 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ù low-key di Git. Mi sembra che le persone che usano Mercurial non siano così facilmente impressionate. Ciò si riflette nel modo in cui ciascun sistema fa ciò che Linus ha descritto come "la più bella fusione MAI!" . In Git puoi unire con un repository non collegato eseguendo:

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

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

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

Notate come i comandi Mercurial sono semplici e non speciali - l'unica cosa insolita è il flag --force in hg pull , che è necessario poiché Mercurial annullerà altrimenti quando si estrae da un repository non correlato. Sono differenze come questa che fanno sembrare Mercurial più elegante per me.


Mi rendo conto che questa non è una parte della risposta, ma su quella nota, penso anche che la disponibilità di plugin stabili per piattaforme come NetBeans ed Eclipse giochino una parte in cui lo strumento è più adatto per l'attività, o meglio, quale strumento è la soluzione migliore per "te". Cioè, a meno che tu non voglia davvero farlo nel modo CLI.

Sia Eclipse (e tutto ciò che si basa su di esso) che NetBeans hanno problemi con i file system remoti (come SSH) e gli aggiornamenti esterni dei file; che è un altro motivo per cui vuoi che tutto ciò che scegli di lavorare "senza problemi".

Sto provando a rispondere a questa domanda per me anche adesso .. e ho riassunto i candidati a Git o Mercurial .. grazie a tutti per aver fornito utili input su questo argomento senza diventare religioso.




Se li capisco correttamente (e sono tutt'altro che un esperto di ciascuno), fondamentalmente ognuno di loro ha una filosofia diversa. Ho usato per la prima volta mercurial per 9 mesi. Ora ho usato git per 6.

hg è un software di controllo della versione. L'obiettivo principale è quello di tenere traccia delle versioni di un software.

git è un file system basato sul tempo. L'obiettivo è aggiungere un'altra dimensione a un file system. La maggior parte ha file e cartelle, git aggiunge tempo. Che capita di funzionare come un VCS è un sottoprodotto del suo design.

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

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 dei file in un particolare stato. Quando spingi o tira git manda solo gli oggetti necessari per i particolari rami che stai spingendo o tirando, che è un piccolo sottoinsieme di tutti gli oggetti.

Per quanto riguarda git non esiste "1 progetto". Potresti avere 50 progetti tutti nello stesso repository e git non gliene importa. Ognuno potrebbe essere gestito separatamente nello stesso pronti contro termine e vivere bene.

Il concetto di rami di Hg è ramificato dal progetto principale o si dirama dai rami ecc. Git non ha questo concetto. Un ramo in git è solo uno stato dell'albero, tutto è un ramo in git. Quale ramo è ufficiale, attuale o più recente non ha alcun significato in git.

Non so se avesse senso. Se potessi disegnare immagini hg potrebbe apparire come questa in cui 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 ne escono. Mentre git può farlo e spesso le persone lo usano in quel modo che non viene applicato. Un'immagine git, se esiste una cosa del genere, potrebbe facilmente apparire come questa

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

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

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

In effetti, in qualche modo non ha nemmeno senso mostrare i rami in git.

Una cosa che è molto confusa per la discussione, sia git che mercurial hanno qualcosa chiamato "ramo" ma non sono lontanamente le stesse cose. Un ramo in mercurio si verifica quando ci sono conflitti tra diversi repository. Un ramo in git è apparentemente simile a un clone in hg. Ma un clone, mentre potrebbe dare un comportamento simile, non è assolutamente lo stesso. Considera che sto provando questi in git vs hg usando il repo 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 il 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

Entrambe sono corse a caldo. Cioè, li ho eseguiti due volte e questa è la seconda manche. hg clone è in realtà lo stesso di git-new-workdir. Entrambi fanno una dir interamente nuova come se avessi digitato cp -r project project-clone . Non è come creare una nuova filiale in git. È molto più pesante. Se esiste un vero equivalente di ramificazione di git in hg, non so cosa sia.

Capisco che a un certo livello hg e git potrebbero essere in grado di fare cose simili. Se è così allora c'è ancora un'enorme differenza nel flusso di lavoro che ti portano. In git, il flusso di lavoro tipico è creare un ramo per ogni funzione.

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

Ha appena creato 3 rami, ciascuno basato su un ramo chiamato master. (Sono sicuro che c'è un modo per far diventare quelle 1 riga ciascuna invece di 2)

Ora per lavorare su quello che faccio e basta

git checkout fix-game-save-bug

e iniziare a lavorare. Commit cose, ecc. Passare da un ramo all'altro in un progetto grande quanto il cromo è quasi istantaneo. In realtà non so come farlo in hg. Non fa parte di alcun tutorial che ho letto.

Un'altra grande differenza. Il palco di Git.

Git ha questa idea di un palcoscenico. Puoi pensarlo come una cartella nascosta. Quando ti impegni, commetti solo ciò che è sul palco, non i cambiamenti nel tuo albero di lavoro. Potrebbe sembrare strano. Se vuoi commettere tutte le modifiche nel tuo albero di lavoro devi fare git commit -a che aggiunge tutti i file modificati allo stage e poi li impegna.

Qual è il punto del palco, allora? Puoi facilmente separare i tuoi commit. Immagina di aver modificato joypad.cpp e gamesave.cpp e vuoi impegnarli 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 i comandi per decidere quali linee particolari nello stesso file si desidera copiare sullo stage in modo da poter suddividere anche questi commit separatamente. Perché vorresti farlo? Poiché come commit separati, gli altri possono tirare solo quelli che vogliono o se c'è un problema possono ripristinare solo il commit che ha avuto il problema.


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

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


Se stai migrando da SVN, usa Mercurial poichè la sua sintassi è MOLTO più comprensibile per gli utenti SVN. Oltre a questo, non puoi sbagliare neanche. Ma controlla il tutorial GIT e HGinit prima di selezionarne uno.


Sono attualmente in procinto di migrare da SVN a DVCS (mentre sto scrivendo sui miei risultati, il mio primo vero sforzo di blogging ...), e ho fatto un po 'di ricerche (= google). Per quanto posso vedere, puoi fare la maggior parte delle cose con entrambi i pacchetti. Sembra che Git abbia alcune funzionalità avanzate implementate più o meglio, credo che l'integrazione con Windows sia un po 'migliore per Mercurial, con TortoiseHg. So che c'è anche Git Cheetah (ho provato entrambi), ma la soluzione mercuriale sembra più robusta.

Vedendo come sono entrambi open-source (giusto?) Non penso che mancheranno funzioni importanti. Se qualcosa è importante, la gente lo chiederà, la gente lo codificherà.

Penso che per le pratiche comuni, Git e Mercurial siano più che sufficienti. Entrambi hanno grandi progetti che li usano (Git -> kernel Linux, Mercurial -> progetti di base di Mozilla, entrambi tra gli altri ovviamente), quindi non credo che manchi davvero qualcosa.

Detto questo, sono interessato a ciò che gli altri dicono di questo, in quanto sarebbe una grande fonte per i miei sforzi di blogging ;-)


Una cosa da notare tra mercurial di bitbucket.org e git di github è, mercurial può avere tanti repository privati ​​quanti ne vuoi, ma github devi aggiornare ad un account a pagamento. Quindi, è per questo che vado per bitbucket che usa mercurial.







dvcs