Git equivalentes de los comandos Mercurial más comunes?

Question

He estado usando Mercurial pero me gustaría hacer una demostración rápida de Git.

¿Cuáles son los equivalentes de Git:

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? 

Answer 1

The Git-HG rosetta stone is not bad

Hay algunos otros aspectos críticos entre los dos no se menciona allí. Esta lista fue copiada de mi propia publicación de blog cuando fui por el otro lado (git -> hg).

Hg .hgignore, sintaxis: glob es el mismo comportamiento que git's .gitignore.

Git .git/config, ~/.gitconfig, utilice git-config para modificar los valores
Hg .hg/hgrc, ~/.hgrc, utilice hg help -c config

Git git commit -v
Hg hg diff | Menos; hg cometer

Git gitk
Hg vista Hg, o THG desde TortoiseHg

Git Git GUI
Hg Mercurial no se distribuye interfaz gráfica de usuario para seleccionar conjuntos de cambios, única consola de comandos hg record .

Git git rebase
Hghg rebase. Para git rebase --interactive hay hg histedit, o Colas de Mercurial

Git Git URL empuje; git remote add origen URL
Hg hg push URL; $ EDITOR .hg/hgrc; [paths] default = URL

Git gitk, git log origin/master ..CABEZA
Hg Hg saliente

Git Git formato de parche GAMA
Hg Hg -m nombre de archivo de correo electrónico -o

Git git add. ; Tenga en cuenta el punto
Hg hg add; Sin punto es necesario.

git checkout git-REVISIÓN CLAVE
Hg hg actualización de cambios

sólo para llenar los espacios en blanco, algunos de los comandos más útiles de Mercurial:

Hg récord hg
Git git add -p; git commit

Hg Hg inc [URL]
Git Sin equivalente real. Sólo se puede hacer equivalente de hg pull; hg log -r .:

Hg Hg cabo URL
Git Por favor, añadir si se sabe cómo.

Para la resolución de conflictos de combinación, el comando hg resolve en Mercurial tiene unas cuantas opciones que cambian el comportamiento:

Hg Hg Archivo Resolver -m (marca el archivo como si hubiera sido resuelto mediante la fijación manualmente el problema de conflicto)
Git Git agregar archivo

Hghg resolve -u FILE marca el archivo como si hubiera sido resuelta
Gitgit reset HEAD FILE a unstage el archivo

Hg -l hg determinación (listas de archivos con conflictos resueltos/sin resolver)
Git git status - los archivos que se fusionaron limpiamente se añaden al índice de forma automática, los que son no tener conflictos

Hg Hg archivo resolver (después de una fusión, los intentos de volver a combinar el archivo)
Git hay un equivalente para la re-fusión º en lo que sé.

Answer 2

Es más o menos lo mismo, sin 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 

Sin embargo, estos son los comandos que usaría cuando se trabaja solo. Entra en el ordenado cosas cuando desea combinar sus cambios con el trabajo de otras personas con git pull y git push, y los comandos relacionados.

Answer 3

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? 

Git Equivalentes:

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

Answer 4

Nota: uno de la mayor diferencia entre Git y Mercurial es la presencia explícita de la índice de o área de ensayo.

De Mercurial for Git User:

Git es la única DistributedSCM que expone el concepto de índice o área de ensayo. Los demás pueden implementarlo y ocultarlo, pero en ningún otro caso el usuario es consciente ni tiene que lidiar con él.

El equivalente aproximado de Mercurial es DirState, que controla la información de estado de copia de trabajo para determinar los archivos que se incluirán en la próxima confirmación. Pero en cualquier caso, este archivo se maneja automáticamente.
Además, es posible ser más selectivo a la hora de confirmación ya sea especificando los archivos que desea confirmar en la línea de comando o usando el RecordExtension.

Si usted se sentía incómodo tratar con el índice, que está cambiando para mejor ;-)

---

El truco es, que realmente necesita para entender el índice de explotar plenamente Git. Como este article from May 2006 nos recuerda entonces (y sigue siendo verdad ahora):

“Si deniega el índice, que realmente niegan git sí”

Ahora, dicho artículo contiene muchos comandos que son ahora más fácil de usar (Así que no confíe demasiado en su contenido;)), pero la idea general permanece:

Está trabajando en una nueva característica y comienza a hacer pequeñas modificaciones en un archivo.

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

En este punto, su próxima confirmación se embarcará 2 modificaciones menores en la rama actual

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

$ git commit 

registros sólo los cambios añadidos al área de ensayo (índice) en este punto, no los grandes cambios actualmente visible en su directorio de trabajo.

$ git branch newFeature_Branch 
$ git add myFile 

La siguiente confirmación registrará todos los demás cambios importantes en la nueva rama 'newFrature_Branch'.

Ahora, añadiendo de forma interactiva o incluso dividir una confirmación son características disponibles con Mercurial, a través del 'hg record' comando u otras extensiones: tendrá que instalar RecordExtension, o la CrecordExtension.
Pero esto no es parte del flujo de trabajo normal de Mercurial.

Git ve una confirmación como una serie de "contenido de archivo cambios", y le permite agregar esos cambios de a uno por vez.
Debe estudiar esa característica y sus consecuencias: la mayor parte de la potencia de Git (como la capacidad de revert a merge (or bisect the problem, or revert a commit), , contrary to Mercurial) proviene de ese paradigma de "contenido de archivo".

---

tonfa (en en el perfil: "dev Hg, pythonist": figuras, ...) intervino, en los comentarios:

No hay nada fundamentalmente "git-ish" en el índice, hg podría usar un índice si se considera valioso, de hecho mq o shelve ya hacen parte de eso.

Oh muchacho. Aquí vamos de nuevo.

Primero, no estoy aquí para hacer que una herramienta se vea mejor que otra. Encuentro Hg genial, muy intuitivo, con un buen soporte (especialmente en Windows, mi plataforma principal, aunque también trabajo en Linux y Solaris8 o 10).

El índice es en realidad frente y al centro en la forma Linus Torvalds works with a VCS:

Git utiliza actualizaciones del índice explícitas desde el día 1, incluso antes de que lo hizo la primera combinación. Es simplemente como siempre he trabajado. Me tienden a tener árboles sucios, con algún parche al azar en mi árbol que hago no quieren comprometerse, porque es sólo una actualización de Makefile para la próxima versión

Ahora la combinación del índice (que no es una noción visto sólo en Git), y el "contenido es el rey" paradigma hace que sea pretty unique and "git-ish":

Git es un rastreador contenido, y un nombre de archivo no tiene sentido a menos asociada a su contenido . Por lo tanto, el único comportamiento razonable para el nombre de archivo de git add es agregar el contenido del archivo así como su nombre al índice.

Nota: el "content", here, is defined as follows:

índice de Git es, básicamente, en gran medida define como

• suficiente para contener el total de "contenido" del árbol (y esto incluye todo metadata: el nombre del archivo, el modo y el contenido del archivo son todos partes del "contenido", ¡y no tienen sentido por sí mismos!)
• información "estadística" adicional para permitir las optimizaciones de comparación del sistema de archivos obvias y triviales (¡pero enormemente importantes!).

lo que realmente debe ver el índice como siendo el contenido.

El contenido no es el "nombre del archivo" o el "contenido del archivo" como partes separadas.Realmente no puedes separar los dos.
Los nombres de archivo por sí solos no tienen sentido (también tienen que tener contenido de archivo), y el contenido del archivo por sí solo no tiene sentido (hay que saber cómo alcanzarlo).

Lo que estoy tratando de decir es que git no permite permitir que vea un nombre de archivo sin su contenido. La noción completa es insana y no válida. No tiene relevancia para la "realidad".

De the FAQ, las principales ventajas son:

• comprometerse con una granularidad fina
• ayuda a mantener una modificación ni comprometer en su árbol por un tiempo razonablemente largo
• realizar varios pasos pequeños para una confirmación, verificando lo que hiciste con git diff y validando cada pequeño paso con git add o git add -u.
• permite una excelente gestión de conflictos de combinación: git diff --base, git diff --ours, git diff --theirs.
• permite git commit --amend a solo modifican el mensaje de registro si el índice no se ha modificado en el ínterin

---

yo personalmente creo este comportamiento no debe ser el valor por defecto, que desea la gente se comprometa algo que se prueba o al menos compilado

Mientras se encuentra justo en general (sobre la parte "probado o compilado"), la forma de Git que permite ramas y la mezcla (cherry picking o cambio de base) que permite cometer tantas veces como desee en una sucursal privada temporal (solo para el repositorio de "copia de seguridad" remota), mientras vuelve a realizar los "commits feos" en una sucursal pública, con todas las pruebas correctas en su lugar.