Sto usando git da qualche tempo su Windows (con msysGit) e mi piace l'idea del controllo del codice sorgente distribuito. Di recente ho visto Mercurial (hg) e sembra interessante. Tuttavia, non riesco ad avvolgere la testa tra le differenze tra hg e git.
Qualcuno ha fatto un confronto fianco a fianco tra git e hg? Sono interessato a sapere cosa differisce da hg e git senza dover saltare in una discussione da fanboy.
Risposte:
Questi articoli possono aiutare:
Modifica : confrontare Git e Mercurial con le celebrità sembra essere una tendenza. Eccone un altro:
Lavoro su Mercurial, ma fondamentalmente credo che entrambi i sistemi siano equivalenti. Entrambi funzionano con le stesse astrazioni: una serie di istantanee (changeset) che compongono la storia. Ogni changeset sa da dove proviene (il changeset genitore) e può avere molti changeset figli. La recente estensione hg-git fornisce un ponte a due vie tra Mercurial e Git e 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 farlo e le conseguenze di farlo sono esattamente ciò che dovresti aspettarti che siano (cioè , se modifico un changeset che già possiedi, il tuo cliente lo vedrà come nuovo se tiri da me). Quindi Mercurial ha una propensione verso comandi non distruttivi.
Per quanto riguarda i rami leggeri, Mercurial ha supportato i repository con più rami da ..., penso sempre. I repository Git con più rami sono esattamente questo: più filoni di sviluppo divergenti in un unico repository. Git quindi aggiunge nomi a questi filoni e consente di interrogare questi nomi da remoto. L' estensione Segnalibri per Mercurial aggiunge nomi locali e con Mercurial 1.6 è possibile spostare questi segnalibri quando si preme / tira.
Uso Linux, ma apparentemente TortoiseHg è più veloce e migliore dell'equivalente Git su Windows (a causa del migliore utilizzo del povero filesystem di Windows). Sia http://github.com che http://bitbucket.org forniscono hosting online, il servizio su Bitbucket è eccezionale e reattivo (non ho provato github).
Ho scelto Mercurial perché mi sembra pulito ed elegante - sono stato scoraggiato dagli script shell / Perl / Ruby che ho ottenuto con Git. Prova a dare una sbirciatina al git-instaweb.shfile se vuoi sapere cosa intendo: è uno script shell che genera uno script Ruby , che a mio avviso gestisce un server web. Lo script della shell genera un altro script della shell per avviare il primo script Ruby. C'è anche un po 'di Perl , per buona misura.
Mi piace il post sul blog che confronta 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 siano così facilmente impressionate. Ciò si riflette nel modo in cui ciascun sistema fa ciò che Linus ha descritto come "la fusione più bella MAI!" . In Git puoi unirti a un repository non correlato effettuando:
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 abbastanza arcani ai miei occhi. In Mercurial facciamo:
hg pull --force <project-to-union-merge>
hg merge
hg commit
Nota come i comandi di Mercurial sono semplici e per niente speciali: l'unica cosa insolita è la --forcebandiera hg pull, che è necessaria poiché Mercurial si interromperà altrimenti quando si estrae da un repository non correlato. Sono differenze come questa che rendono Mercurial più elegante per me.
git pull <url-of-project>. la mail che hai citato è fin dai primissimi giorni di git (2005)
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 di consueto per le app della piattaforma, è più complessa e ha bordi più ruvidi rispetto alle app focalizzate. Ma questo significa anche che VCS di git è estremamente flessibile, e c'è un'enorme profondità di cose che non possono essere controllate da Git con il controllo non sorgente.
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 usare git senza sapere cosa sta succedendo sotto il cofano, finirai per essere confuso (a meno che non ti attenga solo a funzionalità molto basilari). Questo può sembrare stupido quando tutto ciò che vuoi è 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 ':
Ha effettivamente usato entrambi i DVCS ampiamente e li comprende entrambi bene - e ha finito per preferire git.
La grande differenza è su Windows. Mercurial è supportato in modo nativo, Git no. Puoi ottenere un hosting molto simile a github.com con bitbucket.org (in realtà anche meglio se ottieni un repository privato gratuito). Stavo usando msysGit per un po ', ma mi sono trasferito su Mercurial e ne sono rimasto molto soddisfatto.
Se sei uno sviluppatore di Windows alla ricerca di un controllo di revisione disconnesso di base, vai su Hg. Ho trovato Git incomprensibile mentre Hg era semplice e ben integrato con la shell di Windows. Ho scaricato Hg e seguito questo tutorial (hginit.com) - dieci minuti dopo avevo un repository locale ed ero tornato a lavorare sul mio progetto.
Penso che la migliore descrizione di "Mercurial vs. Git" sia:
Sono quasi identici. La differenza più importante, dal mio punto di vista (voglio dire, il motivo che mi ha spinto a scegliere un DVCS rispetto all'altro) è come i due programmi gestiscono i rami.
Per avviare una nuova filiale, con Mercurial, devi semplicemente clonare il repository in un'altra directory e iniziare a sviluppare. Quindi, tirare e unire. Con git, devi dare un nome esplicito al nuovo argomento che vuoi usare, quindi inizi a scrivere usando la stessa directory .
In breve, ogni filiale in Mercurial ha bisogno della propria directory; in git di solito lavori su una singola directory. Cambiare filiale in Mercurial significa cambiare directory; in git, significa chiedere a git di cambiare 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, dal momento che non devo ri -configura Apache e riavvialo e non rovino il mio filesystem ogni volta che mi dirigo.
Modifica: come notato da Deestan, Hg ha nomi di rami , che possono essere memorizzati in un singolo repository e consentire allo sviluppatore di cambiare ramo all'interno della stessa copia di lavoro. i rami git non sono esattamente gli stessi rami di Mercurial, comunque: sono permanenti e non gettano via rami, come in git. Ciò significa che se si utilizza un ramo con nome per attività sperimentali anche se si decide di non unirlo mai, verrà archiviato nel repository. Questo è il motivo per cui Hg incoraggia a usare i cloni per attività sperimentali di breve durata e rami denominati per attività di lunga durata, come per i rami di rilascio.
Il motivo per cui molti utenti di Hg prediligono i cloni su una filiale denominata è 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.
Dall'altro lato, git invita a usare "rami denominati" che non sono permanenti e non sono memorizzati come metadati su ogni changeset.
Dal mio punto di vista personale, quindi, il modello di git è profondamente legato al concetto di rami con nome e passa da un ramo all'altro con la stessa directory; hg può fare lo stesso con i rami con nome, ma tuttavia incoraggia l'uso dei cloni, che personalmente non mi piacciono molto.
C'è un'enorme differenza tra git e mercurial ; il modo in cui rappresentano ogni commit. git rappresenta i commit come istantanee, mentre mercurial li rappresenta come diff.
Cosa significa 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 nell'approccio di mercurial.
Niente. Entrambi fanno lo stesso, entrambi si comportano allo stesso modo. L'unico motivo per cui dovresti scegliere l'uno rispetto all'altro è se ti aiuti con un progetto che ne utilizza già uno.
L'altro possibile motivo per sceglierne uno è un'applicazione o un servizio che supporti solo uno dei sistemi. Ad esempio, ho praticamente scelto di imparare git grazie a github ..
Anche il confronto di Google (anche se è un po 'vecchio, fatto nel 2008)
Se li capisco correttamente (e sono tutt'altro che un esperto in ciascuno) fondamentalmente ognuno di essi ha una filosofia diversa. Ho usato mercurial per 9 mesi. Ora ho usato git per 6.
hg è un software di controllo versione. Il suo obiettivo principale è 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. Il fatto che funzioni alla grande come un VCS è un sottoprodotto del suo design.
In hg, c'è una storia dell'intero progetto che cerca sempre di mantenere. Di default 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 set di quegli oggetti rappresenta l'albero dei file in uno stato particolare. Quando spingi o tira 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 git non ti importerebbe. Ognuno potrebbe essere gestito separatamente nello stesso repository e vivere bene.
Il concetto di Hg di rami è rami del progetto principale o rami di rami ecc. Git non ha tale concetto. Un ramo in git è solo uno stato dell'albero, tutto è un ramo in git. Quale filiale è ufficiale, attuale o più recente non ha alcun significato in Git.
Non so se avesse senso. Se potessi disegnare delle immagini, hg potrebbe apparire così dove ogni commit è ao
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 questo modo che non viene applicato. Un'immagine git, se c'è una cosa del genere, potrebbe facilmente apparire così
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 rami in git.
Una cosa che è molto confusa per la discussione, git e mercurial hanno entrambi qualcosa chiamato "ramo" ma non sono le stesse cose da remoto. Una branca 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, sebbene possa dare un comportamento simile, non è sicuramente lo stesso. Considera di provarli in git vs hg usando il repository di cromo 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 tiri caldi. Cioè, li ho eseguiti due volte e questa è la seconda. hg clone è effettivamente lo stesso di git-new-workdir. Entrambi creano una directory di lavoro completamente nuova quasi come se avessi digitato cp -r project project-clone. Non è lo stesso 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 che hg e git potrebbero essere in grado di fare cose simili. In tal caso, c'è ancora un'enorme differenza nel flusso di lavoro a cui ti portano. In git, il flusso di lavoro tipico è quello di 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
Ciò ha appena creato 3 rami, ognuno basato su un ramo chiamato master. (Sono sicuro che c'è un modo in git di creare quelle 1 linea ciascuna invece di 2)
Ora per lavorare su quello che faccio
git checkout fix-game-save-bug
e inizia a lavorare. Impegnati, ecc. Passare da una filiale all'altra anche in un progetto grande come Chrome è 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 esegui il commit, esegui solo il commit di ciò che è sul palco, non delle modifiche nell'albero di lavoro. Potrebbe sembrare strano. Se si desidera eseguire il commit di tutte le modifiche nella struttura di lavoro, è necessario git commit -aaggiungere tutti i file modificati allo stage e quindi eseguirne il commit.
Qual è il punto del palcoscenico allora? Puoi facilmente separare i tuoi impegni. Immagina di aver modificato joypad.cpp e gamesave.cpp e di volerli commettere 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 dei comandi per decidere quali linee particolari nello stesso file si desidera copiare sullo stage in modo da poter dividere anche quelle commit separatamente. Perché vorresti farlo? Perché come commit separati gli altri possono estrarre solo quelli che vogliono o se c'è stato un problema possono ripristinare solo il commit che ha avuto il problema.
git add --patch, vedere linux.die.net/man/1/git-add o l'uso git add -i, come in stackoverflow.com/questions/2372583/...
checkout -b <name>te potresti semplicemente usare git branch <name>per creare un nuovo branch senza passare ad esso
C'è una tabella comparativa dinamica nel versioncontrolblog in cui è possibile confrontare diversi sistemi di controllo della versione.
dir-a/foo.cdi dir-b/foo.ce continuare a lavorare su dir-b/foo.c, allora il vostro lavoro sul dir-a/foo.csarà correttamente fuse con il mio lavoro dopo un tiro.
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.
Ci sono collaboratori basati su Windows nel tuo progetto?
Perché se ci sono, la GUI di Git-for-Windows sembra imbarazzante, difficile, ostile.
Mercurial-on-Windows, al contrario, è un gioco da ragazzi.
Una cosa da notare tra mercurial di bitbucket.org e git of github è che mercurial può avere tutti i repository privati che vuoi, ma github devi passare a un account a pagamento. Quindi, ecco perché scelgo bitbucket che usa mercurial.
Qualche anno fa ho valutato sia git che hg per il mio uso e ho deciso di andare con hg. Mi sembrava che fosse una soluzione più pulita e all'epoca funzionava meglio su più piattaforme. Per lo più, però, è stata per lo più una confusione.
Più recentemente, ho iniziato a usare git a causa di git-svn e della 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 (specialmente se hai bisogno di curiosare all'interno), ma è davvero un ottimo sistema. Vado a leggere quei due articoli di confronto che John ha pubblicato ora.
Attualmente sto migrando da SVN a un DVCS (mentre bloggando sulle mie scoperte, il mio primo vero sforzo di blogging ...), e ho fatto un po 'di ricerche (= googling). 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, penso 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 neanche a nessuno mancheranno importanti funzionalità. 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 della Mozilla Foundation, entrambi ovviamente tra gli altri), quindi non credo che manchi davvero qualcosa.
Detto questo, sono interessato a ciò che gli altri dicono di questo, in quanto sarebbe un'ottima fonte per i miei sforzi di blog ;-)
C'è una grande ed esaustiva tabella di confronto e grafici su git, Mercurial e Bazaar nella guida di InfoQ sul DVCS .
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 abbia un ruolo in cui lo strumento si adatta meglio all'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 basato su di esso) che NetBeans a volte hanno problemi con i file system remoti (come SSH) e gli aggiornamenti esterni dei file; che è ancora un altro motivo per cui si desidera che tutto ciò che si sceglie di lavorare "senza soluzione di continuità".
Sto cercando di rispondere a questa domanda anche per me stesso 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 vs 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 girano entrambi in buoni numeri, ma fanno un interessante compromesso tra velocità e dimensioni del repository. Mercurial è veloce sia con aggiunte che con modifiche e tiene sotto controllo la crescita del repository allo stesso tempo. Git è anche veloce, ma il suo repository cresce molto rapidamente con i file modificati fino a quando non li reimballi, e questi repack possono essere molto lenti. Ma il repository pieno è molto più piccolo di quello di Mercurial.
Il sito web mercuriale ha una grande descrizione delle somiglianze e delle differenze tra i due sistemi, spiegando le differenze di vocabolario e concetti sottostanti. Come utente git da molto tempo, mi ha davvero aiutato a capire 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 GIT tutorial e HGinit prima di selezionarne uno.
Questo link può aiutarti a capire la differenza http://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 dottorandi in materia 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: l'ingegneria del software. Mercurial consente agli utenti di utilizzare e abusare felicemente del sistema senza far loro commettere errori non recuperabili.
Qualsiasi strumento professionale deve avere una CLI chiaramente progettata e intuitiva. Gli utenti di Mercurial possono eseguire la maggior parte del lavoro emettendo semplici comandi senza alcuna strana opzione. In Git doppio trattino, le opzioni folli sono la norma. Mercurial ha un vantaggio sostanziale se sei un CLI (e, a dire il vero, qualsiasi Ingegnere del Software che si rispetti dovrebbe essere).
Per fare un esempio, supponiamo che tu commetta un errore per errore. Hai dimenticato di modificare alcuni file. Per annullare l'azione in Mercurial, digita semplicemente:
$ hg rollback
Viene quindi visualizzato il messaggio che il sistema annulla l'ultima transazione.
In Git devi digitare:
$ git reset --soft HEAD^
Quindi ok supponi di avere un'idea di cosa sia il reset. Inoltre, devi sapere quali sono i ripristini "--soft" e "--hard" (qualche ipotesi intuitiva?). Oh e ovviamente non dimenticare il carattere '^' alla fine! (ora quello che nel nome di Ritchie è che ...)
Anche l'integrazione di Mercurial con strumenti di terze parti come kdiff3 e meld è molto migliore. Genera le tue patch unisci i tuoi rami senza troppe storie. Mercurial include anche un semplice server http che si attiva digitando
hg serve
E lascia che gli altri esplorino il tuo repository.
La linea di fondo è, 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 fare il lavoro VCS senza preoccupartene molto e concentrarti sui tuoi compiti reali.