Git equivalenti dei comandi Mercurial più comuni?

Sto usando Mercurial ma vorrei fare una rapida demo di Git.

Quali sono gli equivalenti Git di:

hg init . # start a project in the current directory hg addremove # look for any added or deleted files hg commit -m "comment" # commit any uncomitted changes hg status # what have i changed since the last commit? 

La pietra rosetta Git-HG non è male

Ci sono alcuni altri trucchi tra i due non menzionati qui. Questa lista è stata criptata dal mio post sul blog quando sono andato dall’altra parte (git -> hg).

Hg .hgignore, syntax: glob è lo stesso comportamento di git’s .gitignore.

Git .git / config, ~ / .gitconfig, usa git-config per modificare i valori
Hg .hg / hgrc, ~ / .hgrc, usa hg help -c config

Git git commit -v
Hg hg diff | Di meno; hg commit

Git Gitk
Hg hg view, o thg da TortoiseHg

Git git gui
Hg Mercurial non spedisce GUI per selezionare i changeset, solo il comando di console hg record .

Git git rebase
Hg hg rebase . Per git rebase --interactive ci sono hg histedit o Mercurial Queues

Git git push URL; git remote aggiunge l’URL di origine
Hg hg push URL; $ EDITOR .hg / hgrc; [percorsi] default = URL

Git gitk, git log origin / master..HEAD
Hg hg in uscita

Git git formato-patch RANGE
Hg hg email -m nomefile -o

Git git add. ; Nota il punto
Hg hg add; Non è necessario alcun punto.

Git git checkout REVISION-KEY
Hg hg update CHANGESET

Solo per riempire gli spazi vuoti, alcuni dei comandi più utili di Mercurial:

Hg hg record
Git git add -p; Git commit

Hg hg inc [URL]
Git Nessun vero equivalente. Puoi fare solo l’equivalente di hg pull; hg log -r .: hg pull; hg log -r .:

Hg hg out URL
Git Per favore aggiungi se sai come.

Per unire la risoluzione dei conflitti, il comando hg resolve in Mercurial ha alcune opzioni che modificano il comportamento:

Hg hg resolve -m FILE (contrassegna il file come risolto risolvendo manualmente il problema di conflitto)
Git git aggiungi FILE

Hg hg resolve -u FILE indica che il file è rimasto irrisolto
Git git reset HEAD FILE per rimuovere il file

Hg hg resolve -l (elenca i file con conflitti risolti / non risolti)
Git git status: i file che vengono uniti in modo pulito vengono aggiunti automaticamente all’indice, quelli che non hanno conflitti

Hg hg risolve FILE (dopo l’unione, tenta di ri-unire il file)
Non sono un equivalente per riunire di nuovo ciò che so.

Nota: una delle maggiori differenze tra Git e Mercurial è la presenza esplicita dell’indice o dell’area di staging .

Da Mercurial per l’utente Git :

Git è l’unico DistributedSCM che espone il concetto di indice o area di staging. Gli altri possono implementarlo e nasconderlo, ma in nessun altro caso l’utente è consapevole e non deve occuparsene.

L’equivalente approssimativo di Mercurial è DirState , che controlla le informazioni sullo stato della copia di lavoro per determinare i file da includere nel commit successivo. Ma in ogni caso, questo file viene gestito automaticamente.
Inoltre, è ansible essere più selettivi al momento del commit specificando i file che si desidera eseguire il commit sulla riga di comando o utilizzando RecordExtension .

Se ti senti a disagio nel gestire l’indice, stai passando per il meglio 😉


Il trucco è che devi davvero capire l’indice per sfruttare pienamente Git. Come ci ricorda questo articolo del maggio 2006 (ed è ancora vero ora):

“Se neghi l’Indice, neghi davvero Git stesso.”

Ora, quell’articolo contiene molti comandi che sono ora più semplici da usare (quindi non fare troppo affidamento sul suo contenuto;)), ma l’idea generale rimane:

Stai lavorando su una nuova funzione e inizia a fare piccole modifiche su un file.

 # working, add a few lines $ git add myFile # working, another minor modification $ git add myFile 

A questo punto, il tuo prossimo commit eseguirà 2 modifiche minori nel ramo corrente

 # working, making major modification for the new features # ... damn! I cannot commit all this in the current branch: nothing would work $ git commit 

Registra solo le modifiche aggiunte all’area di staging (indice) a questo punto, non le principali modifiche attualmente visibili nella directory di lavoro.

 $ git branch newFeature_Branch $ git add myFile 

Il prossimo commit registrerà tutte le altre principali modifiche nel nuovo ramo ‘newFrature_Branch’.

Ora, aggiungendo in modo interattivo o anche dividendo un commit sono disponibili le funzioni con Mercurial, tramite il comando ‘ hg record ‘ o altre estensioni: sarà necessario installare RecordExtension , o CrecordExtension .
Ma questo non fa parte del normale stream di lavoro di Mercurial.

Git visualizza un commit come una serie di “modifiche del contenuto del file ” e consente di aggiungere tali modifiche una alla volta.
Dovresti studiare questa caratteristica e le sue conseguenze: la maggior parte del potere di Git (come la possibilità di ripristinare facilmente un’unione (o bisecare il problema o ripristinare un commit) , contrariamente a Mercurial ) deriva da quel paradigma del “file content”.


tonfa (nel profilo: “Hg dev, pythonist”: figure …) è intervenuto, nei commenti:

Non c’è niente di fondamentalmente “git-ish” nell’indice, hg potrebbe usare un indice se fosse ritenuto prezioso, infatti mq o shelve ne fanno già parte.

Oh ragazzo. Ci risiamo.

Innanzitutto, non sono qui per rendere uno strumento migliore di un altro. Trovo Hg fantastico, molto intuitivo, con un buon supporto (specialmente su Windows, la mia piattaforma principale, anche se lavoro su Linux e su Solaris8 o 10).

L’indice è in realtà frontale e centrale nel modo in cui Linus Torvalds lavora con un VCS :

Git ha utilizzato gli aggiornamenti dell’indice espliciti dal primo giorno, anche prima della prima unione. È semplicemente come ho sempre lavorato. Tendo ad avere alberi sporchi, con qualche patch casuale nel mio albero che non voglio commettere, perché è solo un aggiornamento Makefile per la prossima versione

Ora la combinazione dell’indice (che non è una nozione vista solo in Git), e il paradigma “content is king” lo rende piuttosto unico e “git-ish” :

git è un tracker di contenuti e un nome di file non ha significato se non è associato al suo contenuto. Pertanto, l’unico comportamento corretto per git add filename è quello di aggiungere il contenuto del file e il suo nome all’indice.

Nota: il “contenuto”, qui, è definito come segue :

L’indice di Git è fondamentalmente molto definito come

  • sufficiente a contenere il ” contenuto ” totale dell’albero (e questo include tutti i metadati: il nome file, la modalità e il contenuto del file sono tutte parti del “contenuto”, e sono tutti privi di significato da soli! )
  • ulteriori informazioni “stat” per consentire l’ovvia e banale (ma enormemente importante!) ottimizzazione del confronto del filesystem.

Quindi dovresti davvero vedere l’indice come il contenuto .

Il contenuto non è il “nome del file” o il “contenuto del file” come parti separate. Non puoi davvero separare i due .
I nomi dei file da soli non hanno senso (devono avere anche il contenuto del file), e il contenuto del file da solo è altrettanto insensato (devi sapere come raggiungerlo).

Quello che sto cercando di dire è che git fondamentalmente non ti permette di vedere un nome di file senza il suo contenuto. L’intera nozione è folle e non valida. Non ha rilevanza per la “realtà”.

Dalle FAQ , i principali vantaggi sono:

  • commettere con una granularità fine
  • ti aiutano a mantenere una modifica senza restrizioni nell’albero per un tempo ragionevolmente lungo
  • esegui diversi piccoli passi per un commit, verificando cosa hai fatto con git diff e convalidando ogni piccolo passo con git add o git add -u .
  • consente un’eccellente gestione dei conflitti di fusione: git diff --base , git diff --ours , git diff --theirs .
  • consente a git commit --amend di modificare solo il messaggio di log se l’indice non è stato modificato nel frattempo

Personalmente ritengo che questo comportamento non dovrebbe essere l’impostazione predefinita, vuoi che le persone commettano qualcosa che è stato testato o almeno compilato

Sebbene tu abbia ragione in generale (riguardo alla parte “testata o compilata”), il modo in cui Git ti permette di ramificarti e fonderti (cherry-picking o rebasing) ti permette di impegnarti tutte le volte che vuoi in un ramo privato temporaneo (solo spinto al repository “di backup” remoto), mentre rifatti quei “brutti commit” su un ramo pubblico, con tutti i test giusti.

Mercurial:

 hg init . # start a project in the current directory hg addremove # look for any added or deleted files hg commit -m "comment" # commit any uncomitted changes hg status # what have i changed since the last commit? 

Equivalenti Git:

 git init git add -A git commit -am "comment" # -a is not necessary along with the above add -A git status 

È più o meno la stessa cosa, senza addremove:

 git init # Start a project in the current directory git status # Displays both changes and added/removed files git commit -m "comment" # commit any uncommited changes 

Tuttavia, questi sono comandi che useresti quando lavori da solo. Entrate nel merito quando volete unire le vostre modifiche con il lavoro di altre persone con git pull e git push e i relativi comandi.