tener - tipos de etiquetas en git

Git equivalentes de los comandos Mercurial más comunes? (4)

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 comandos que usarías cuando trabajas solo. Te dedicas a lo mejor cuando quieres fusionar tus cambios con el trabajo de otras personas con git pull y git push , y los comandos relacionados.

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

¿Cuáles son los equivalentes de Git de:

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?

Mercurial:

Equivalentes de Git:

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

Nota: una de las mayores diferencias entre Git y Mercurial es la presencia explícita del índice o área de ensayo .

De Mercurial para el usuario de Git :

Git es el único 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 el DirState , que controla la información del estado de la 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 en el momento de la confirmación ya sea especificando los archivos que desea confirmar en la línea de comando o utilizando la RecordExtension .
Si te sientes incómodo lidiando con el índice, estás cambiando para mejor ;-)

El truco es que realmente necesitas entender el índice para explotar por completo a Git. Como nos recuerda este artículo de mayo de 2006 (y sigue siendo cierto ahora):

"Si niegas el índice, realmente niegas a git".

Ahora, ese artículo contiene muchos comandos que ahora son más simples 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 modificaciones menores en un archivo.

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

En este punto, su próximo commit 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

Solo registra los cambios agregados al área de ensayo (índice) en este momento, no los cambios principales actualmente visibles en su directorio de trabajo.

$ git branch newFeature_Branch $ git add myFile

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

Ahora, agregar de forma interactiva o incluso dividir un commit son funciones disponibles con Mercurial, a través del comando '' hg record '' u otras extensiones: necesitará instalar RecordExtension , o CrecordExtension .
Pero esto no es parte del flujo de trabajo normal de Mercurial.

Git ve una confirmación como una serie de "cambios en el contenido del archivo ", y le permite agregar esos cambios de uno en uno.
Debería estudiar esa característica y sus consecuencias: la mayor parte de la potencia de Git (como la capacidad de revertir fácilmente una combinación (o dividir el problema en dos, o revertir una confirmación) , al contrario de Mercurial ) proviene de ese paradigma de "contenido de archivo".

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

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

Oh chico. 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 realmente frontal y central en la forma en que Linus Torvalds trabaja con un VCS :

Git usó actualizaciones de índice explícitas desde el día 1, incluso antes de que hiciera la primera fusión. Es simplemente como siempre he trabajado. Tiendo a tener árboles sucios, con algún parche al azar en mi árbol que no quiero comprometer, porque es solo una actualización de Makefile para la próxima versión

Ahora, la combinación del índice (que no es una noción que solo se ve en Git) y el paradigma de "el contenido es el rey" lo hace bastante único y "git-ish" :

git es un rastreador de contenido , y un nombre de archivo no tiene ningún significado a menos que esté asociado 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 "contenido", aquí, se define de la siguiente manera :

El índice de Git básicamente está muy definido como
suficiente para contener el " contenido " total del árbol (y esto incluye todos los metadatos: el nombre de archivo, el modo y el contenido del archivo son todas partes del "contenido", ¡y no tienen sentido por sí mismos! )
información adicional "estadística" para permitir las optimizaciones de comparación de sistemas de archivos obvias y triviales (¡pero enormemente importantes!).
Entonces, realmente debería ver el índice como el contenido .
El contenido no es el "nombre de 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 deben tener contenido de archivo) y el contenido del archivo por sí solo no tiene sentido (hay que saber cómo llegar a él).
Lo que trato de decir es que git no te permite ver un nombre de archivo sin su contenido. La noción completa es insana y no válida. No tiene relevancia para la "realidad".

De las preguntas frecuentes , las principales ventajas son:

comprometerse con una granularidad fina
te ayuda a mantener una modificación sin compromiso en tu árbol durante un tiempo razonablemente largo
realice varios pasos pequeños para una confirmación, verifique lo que hizo con git diff y valide cada pequeño paso con git add o git add -u .
permite una gestión excelente de los conflictos de fusión: git diff --base , git diff --ours , git diff --theirs .
permite que git commit --amend modifique solo el mensaje de registro si el índice no se ha modificado mientras tanto

Personalmente, creo que este comportamiento no debe ser el predeterminado, quiere que las personas confirmen algo que se prueba o al menos compilado

Si bien tiene razón en general (acerca de la parte "probada o compilada"), la forma en que Git le permite ramificarse y fusionarse (seleccionar o volver a basar) le permite comprometerse tan a menudo como desee en una sucursal privada temporal (solo empujada) al repositorio de "copia de seguridad" remota), mientras se repiten los "commits feos" en una rama pública, con todas las pruebas correctas en su lugar.

La piedra rosetta Git-HG no está mal

Hay algunos otros problemas entre los dos que no se mencionan 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, use git-config para modificar los valores
Hg .hg / hgrc, ~ / .hgrc, use hg help -c config

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

Git Gitk
Hg hg view, o thg de TortoiseHg

Git git gui
Hg Mercurial no envía GUI para seleccionar conjuntos de cambios, solo el comando hg record console.

Git git rebase
Hg hg rebase . Para git rebase --interactive hay hg histedit , o Mercurial Queues

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

Git gitk, git log origen / maestro ... HEAD
Hg hg saliente

Git git formato-parche RANGE
Hg hg email -m nombre de archivo -o

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

Git git checkout REVISION-KEY
Hg hg update CHANGESET

Solo para completar los espacios en blanco, algunos de los comandos más útiles de Mercurial:

Hg hg record
Git git add -p; git commit

Hg hg inc [URL]
Git Sin equivalente real. Solo puedes hacer el equivalente de hg pull; hg log -r .: hg pull; hg log -r .:

Hg hg URL
Git Por favor, agrega si sabes cómo.

Para fusionar resolución de conflictos, el comando hg resolve en Mercurial tiene algunas opciones que cambian el comportamiento:

Hg hg resolve -m FILE (marca el archivo como resuelto arreglando manualmente el problema de conflicto)
Git git agregar ARCHIVO

Hg hg resolve -u FILE marca el archivo como no resuelto
Git git reset HEAD FILE para dejar de grabar el archivo

Hg hg resolve -l (lista los archivos con conflictos resueltos / no resueltos)
Estado de Git Git : los archivos que se fusionaron limpiamente se agregan automáticamente al índice, aquellos que no tienen conflictos

Hg hg resolve FILE (después de una fusión, intenta volver a fusionar el archivo)
Git no tiene equivalente para volver a fusionar que yo sepa.