Pregunta ¿Cuál es la diferencia entre Mercurial y Git?


He estado usando git por un tiempo en Windows (con msysGit) y me gusta la idea del control de fuente distribuida. Hace poco estuve mirando Mercurial (hg) y parece interesante. Sin embargo, no puedo entender las diferencias entre hg y git.

¿Alguien ha hecho una comparación lado a lado entre git y hg? Estoy interesado en saber qué difiere hg y git sin tener que saltar a una discusión fanboy.


729


origen


Respuestas:


Estos artículos pueden ayudar:

Editar: Comparar Git y Mercurial con celebridades parece ser una tendencia. Aquí hay uno más:


345



Trabajo en Mercurial, pero fundamentalmente creo que ambos sistemas son equivalentes. Ambos trabajan con las mismas abstracciones: una serie de instantáneas (conjuntos de cambios) que componen la historia. Cada conjunto de cambios sabe de dónde vino (el conjunto de cambios principal) y puede tener muchos conjuntos de cambios secundarios. El reciente hg-git la extensión proporciona un puente de dos vías entre Mercurial y Git y muestra este punto en cierta forma.

Git tiene un fuerte enfoque en la mutación de este gráfico de historia (con todas las consecuencias que eso conlleva), mientras que Mercurial no fomenta la reescritura de la historia, pero es fácil de hacer de todos modos y las consecuencias de hacerlo son exactamente lo que debería esperar que sean (es decir, si modifico un conjunto de cambios que ya tiene, su cliente lo verá como nuevo si lo extrae de mí). Entonces Mercurial tiene un parcialidad hacia comandos no destructivos.

En cuanto a las sucursales livianas, Mercurial tiene repositorios compatibles con ramas múltiples desde ..., siempre pienso. Los repositorios de Git con múltiples ramas son exactamente eso: múltiples líneas de desarrollo divergentes en un único repositorio. Git luego agrega nombres a estos hilos y le permite consultar estos nombres de forma remota. los Marcadores extensión para Mercurial agrega nombres locales, y con Mercurial 1.6, puede mover estos marcadores cuando empuja / tira ...

Uso Linux, pero al parecer TortoiseHg es más rápido y mejor que el equivalente de Git en Windows (debido a un mejor uso del pobre sistema de archivos de Windows). Ambos http://github.com y http://bitbucket.org proporcionar alojamiento en línea, el servicio en Bitbucket es excelente y receptivo (no he probado github).

Elegí Mercurial, ya que se siente limpio y elegante, me desanimaron los guiones de shell / Perl / Ruby que obtuve con Git. Intente echar un vistazo a la git-instaweb.sh archivo si quieres saber a qué me refiero: es un cáscara script que genera un Rubí script, que creo que ejecuta un servidor web. El script de shell genera otro script de shell para iniciar el primer script de Ruby. También hay un poco de Perl, para una buena medida.

me gusta el entrada en el blog eso compara a Mercurial y Git con James Bond y MacGyver: Mercurial es de alguna manera más discreto que Git. Me parece que las personas que usan Mercurial no se impresionan tan fácilmente. Esto se refleja en la forma en que cada sistema hace lo que Linus describió como "¡La mejor fusión jamás!". En Git puedes fusionar con un repositorio no relacionado haciendo:

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

Esos comandos parecen bastante arcanas a mi vista. En Mercurial hacemos:

hg pull --force <project-to-union-merge>
hg merge
hg commit

Observe cómo los comandos de Mercurial son simples y nada especiales: lo único inusual es --force bandera para hg pull, que es necesario ya que Mercurial abortará de otra forma cuando saque de un repositorio no relacionado. Son diferencias como esta las que hacen que Mercurial me parezca más elegante.


238



Git es una plataforma, Mercurial es "solo" una aplicación. Git es una plataforma de sistema de archivos versionada que se envía con una aplicación DVCS en la caja, pero como es normal para las aplicaciones de plataforma, es más compleja y tiene bordes más ásperos que las aplicaciones enfocadas. Pero esto también significa que el VCS de git es inmensamente flexible, y hay una gran cantidad de cosas que no son de control de fuente que puedes hacer con git.

Esa es la esencia de la diferencia.

Git se entiende mejor desde cero, desde el formato de repositorio arriba. Charla Git de Scott Chacon es una excelente base para esto. Si tratas de usar git sin saber lo que sucede debajo del capó, terminarás confundido en algún momento (a menos que te limites a funciones muy básicas). Esto puede sonar estúpido cuando todo lo que quiere es un DVCS para su rutina de programación diaria, pero la genialidad de git es que el formato del repositorio es realmente muy simple y usted poder entender toda la operación de git con bastante facilidad.

Para algunas comparaciones más orientadas a la técnica, los mejores artículos que he visto personalmente son Dustin Sallings ':

Él realmente ha usado ambos DVCS extensamente y los entiende bien a ambos, y terminó prefiriendo a git.


73



La gran diferencia está en Windows. Mercurial es compatible de forma nativa, Git no lo es. Puede obtener un hosting muy similar a github.com con bitbucket.org (en realidad, incluso mejor cuando obtiene un repositorio privado gratuito). Estaba usando msysGit por un tiempo, pero me mudé a Mercurial y estoy muy contento con él.


51



Si usted es un desarrollador de Windows que busca el control de revisión desconectado básico, vaya con Hg. Encontré que Git era incomprensible mientras que Hg era simple y estaba bien integrado con el shell de Windows. Descargué Hg y seguí este tutorial (hginit.com) - Diez minutos después tuve un repositorio local y volví a trabajar en mi proyecto.


38



Creo que la mejor descripción sobre "Mercurial vs. Git" es:

"Git es Wesley Snipes. Mercurial es Denzel Washington"


22



Ellos son casi idénticos. La diferencia más importante, desde mi punto de vista (es decir, el motivo que me llevó a elegir un DVCS sobre el otro) es cómo los dos programas administran las sucursales.

Para comenzar una nueva rama, con Mercurial, simplemente clona el repositorio a otro directorio y comienza a desarrollar Entonces, tiras y fusionas. Con git, tienes que dar un nombre explícito a la nueva rama de tema que quieres usar, luego comienzas a codificar usando el mismo directorio.

En resumen, cada sucursal en Mercurial necesita su propio directorio; en git generalmente trabajas en un solo directorio. Cambiar de sucursales en Mercurial significa cambiar directorios; en git, significa pedirle a git que cambie el contenido del directorio con git checkout.

Soy honesto: no sé si es posible hacer lo mismo con Mercurial, pero como normalmente trabajo en proyectos web, usar siempre el mismo directorio con git me parece muy cómodo, ya que no tengo que volver a hacerlo. -configurar Apache y reiniciarlo y no ensucie mi sistema de archivos cada vez que me ramifico.

Editar: Como señaló Deestan, Hg tiene ramas nombradas, que puede almacenarse en un único repositorio y permitir al desarrollador cambiar de rama dentro de la misma copia de trabajo. Las ramas git no son exactamente iguales a las ramas nombradas Mercurial, de todos modos: son permanentes y no tiran ramas, como en git. Eso significa que si usa una rama con nombre para tareas experimentales, incluso si decide nunca fusionarla, se almacenará en el repositorio. Esa es la razón por la cual Hg anima a usar clones para tareas experimentales, de ejecución corta y ramas con nombre para tareas de ejecución prolongada, como para las ramas de publicación.

La razón por la que muchos usuarios de Hg prefieren clones a una rama con nombre es mucho más social o cultural que técnica. Por ejemplo, con las últimas versiones de Hg, incluso es posible cerrar una rama con nombre y eliminar metadatos recursivamente de los conjuntos de cambios.

Por otro lado, git invita a usar "ramas con nombre" que no son permanentes y no se almacenan como metadatos en cada conjunto de cambios.

Desde mi punto de vista personal, entonces, el modelo de git está profundamente vinculado al concepto de ramas con nombre y alternar entre una rama y otra dentro del mismo directorio; hg puede hacer lo mismo con las ramas nombradas, pero aún fomenta el uso de clones, que personalmente no me gustan demasiado.


20