version-control push - Qual è la differenza tra Mercurial e Git?




tag remove (21)

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.


Answers

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.


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.





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.


Niente. Entrambi fanno lo stesso, entrambi si comportano allo stesso modo. L'unica ragione per cui devi scegliere l'una sull'altra è se aiuti con un progetto che già ne usa 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 ..


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 ;-)


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.



Esiste una grande ed esauriente tabella di confronto e grafici su git, Mercurial e Bazaar sulla guida di InfoQ su DVCS .


Ci sono dei collaboratori basati su Windows sul tuo progetto?

Perché se ci sono, la GUI di Git-per-Windows sembra imbarazzante, difficile, scostante.

Mercurial-on-Windows, al contrario, è un gioco da ragazzi.


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.



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.


Se sei uno sviluppatore di Windows in cerca di controllo di revisione disconnessi di base, vai con 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 ho avuto un repo locale e sono tornato a lavorare al mio progetto.


Sono quasi identici. La differenza più importante, dal mio punto di vista (voglio dire, la ragione che mi ha spinto a scegliere un DVCS rispetto all'altro) è come i due programmi gestiscono le filiali.

Per avviare un nuovo ramo, con Mercurial, basta semplicemente clonare il repository in un'altra directory e iniziare a sviluppare. Quindi, tiri e unisci. Con git, devi dare un nome esplicito al nuovo ramo dell'argomento che vuoi usare, quindi inizi la codifica usando la stessa directory .

In breve, ogni ramo in Mercurial ha bisogno di una propria directory; in git di solito lavori su un'unica directory. Commutare rami 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 è 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 più confortevole, dato che non devo -configure Apache e riavvialo e non rovino il mio filesystem ogni volta che mi dirigo.

Modifica: come notato da Deestan, Hg ha nominato i rami , che possono essere archiviati in un unico repository e consentire allo sviluppatore di cambiare ramo all'interno della stessa copia di lavoro. i rami git non sono esattamente uguali ai rami Mercurial, comunque: sono permanenti e non gettano via rami, come in git. Ciò significa che se si utilizza un ramo nominato per attività sperimentali anche se si decide di non fonderlo, esso verrà memorizzato nel repository. Questo è il motivo per cui Hg incoraggia l'uso di 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 Hg preferiscono i cloni sul ramo nominato è molto più sociale o culturale che tecnico. Ad esempio, con le ultime versioni di Hg, è persino possibile chiudere un ramo con nome e rimuovere in modo ricorsivo i metadati dai changeset.

D'altra parte, git invita ad usare "named branches" che non sono permanenti e non sono memorizzati come metadati su ciascun changeset.

Dal mio personale punto di vista, quindi, il modello di git è profondamente legato al concetto di rami nominati e passa da un ramo all'altro con la stessa directory; hg può fare lo stesso con i rami nominati, ma tuttavia incoraggia l'uso dei cloni, che personalmente non mi piace troppo.


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.


La grande differenza è su Windows. Mercurial è supportato in modo nativo, Git non lo è. È possibile ottenere hosting molto simile a github.com con bitbucket.org (in realtà è ancora meglio se si ottiene un repository privato gratuito). Stavo usando msysGit per un po ', ma mi sono trasferito su Mercurial e ne sono stato molto contento.


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.


Ecco i passaggi per rinominare il ramo:

1. switch to branch which needs to be renamed
2. git branch -m <new_name>
3. git push origin :<old_name>
4. git push origin <new_name>:refs/heads/<new_name>

EDIT (12/01/2017): assicurati di eseguire lo git status comando e controlla che il ramo appena creato stia puntando al proprio riferimento e non a quello precedente. Se trovi il riferimento al ramo più vecchio, devi disinserire l'upstream usando:

git branch --unset-upstream




git version-control mercurial comparison dvcs