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

StackOverflow https://stackoverflow.com/questions/35837

Pregunta

He estado usando git desde hace algún tiempo en Windows (con msysGit) y me gusta la idea del control de fuente distribuida.Recientemente 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?Me interesa saber en qué se diferencia hg y git sin tener que entrar en una discusión de fans.

¿Fue útil?

Solución

Estos artículos pueden ayudar:

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

Otros consejos

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 el historial.Cada conjunto de cambios sabe de dónde viene (el conjunto de cambios principal) y puede tener muchos conjuntos de cambios secundarios.El reciente hg-git La extensión proporciona un puente bidireccional entre Mercurial y Git y muestra este punto.

Git tiene un fuerte enfoque en mutar este gráfico histórico (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 las que usted debería esperar que sean (es decir, si modifico un conjunto de cambios que ya tiene, su cliente lo verá como nuevo si lo retira de mí).Entonces Mercurial tiene un inclinación hacia comandos no destructivos.

En cuanto a las ramas livianas, Mercurial ha admitido repositorios con múltiples sucursales desde..., siempre pienso.Los repositorios de Git con múltiples ramas son exactamente eso:múltiples líneas divergentes de desarrollo en un único repositorio.Luego, Git agrega nombres a estos hilos y le permite consultar estos nombres de forma remota.El Marcadores La extensión para Mercurial agrega nombres locales, y con Mercurial 1.6, puedes mover estos marcadores cuando empujas o tiras.

Utilizo Linux, pero aparentemente TortoiseHg es más rápido y mejor que el equivalente de Git en Windows (debido al mejor uso del deficiente 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 porque se siente limpio y elegante; me desanimaron los scripts de Shell/Perl/Ruby que obtuve con Git.Intente echar un vistazo al git-instaweb.sh archivo si quieres saber a qué me refiero:es un caparazón 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 perla, para una buena medida.

me gusta el entrada en el blog que compara Mercurial y Git con James Bond y MacGyver: Mercurial es de alguna manera más discreto que Git.Me parece que la gente que usa Mercurial no se impresiona tan fácilmente.Esto se refleja en cómo cada sistema hace lo que Linus describió como "¡La fusión más genial de todos los tiempos!".En Git puedes fusionarte 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

Esas órdenes me parecen bastante arcanas.En Mercurial hacemos:

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

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

Git es una plataforma, Mercurial es “solo” una aplicación.Git es una plataforma de sistema de archivos versionada que viene con una aplicación DVCS en la caja, pero como es normal en las aplicaciones de plataforma, es más compleja y tiene aspectos 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 sin control de fuente que puedes hacer con git.

Ésa es la esencia de la diferencia.

Git se entiende mejor desde cero, desde el formato del repositorio. Charla sobre Git de Scott Chacón es una excelente base para esto.Si intentas usar git sin saber lo que sucede bajo el capó, terminarás confundido en algún momento (a menos que te limites a una funcionalidad muy básica).Esto puede parecer estúpido cuando todo lo que quieres es un DVCS para tu rutina de programación diaria, pero la genialidad de git es que el formato del repositorio es realmente muy simple y poder entender toda la operación de git con bastante facilidad.

Para algunas comparaciones más técnicas, los mejores artículos que he visto personalmente son los de Dustin Sallings:

De hecho, ha utilizado ampliamente ambos DVCS y los comprende bien, y terminó prefiriendo git.

La gran diferencia está en Windows.Mercurial es compatible de forma nativa, Git no.Puedes conseguir hosting muy similar a github.com con bitbucket.org (En realidad, incluso mejor, ya que obtienes un repositorio privado gratuito).Estuve usando msysGit por un tiempo, pero me pasé a Mercurial y estoy muy contento con él.

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

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

"Git es Wesley Snipes.Mercurial es Denzel Washington"

Son casi idénticos.La diferencia más importante, desde mi punto de vista (quiero decir, la razón que me llevó a elegir un DVCS sobre el otro) es cómo los dos programas gestionan las sucursales.

Para iniciar una nueva rama, con Mercurial, simplemente clona el repositorio a otro directorio y empezar a desarrollar.Luego, tiras y fusionas.Con git, debes darle explícitamente un nombre a la nueva rama del tema que deseas usar, luego comienzas a codificar. usando el mismo directorio.

En resumen, cada sucursal de Mercurial necesita su propio directorio;En git normalmente trabajas en un solo directorio.Cambiar de sucursal en Mercurial significa cambiar de directorio;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 suelo trabajar en proyectos web, usar siempre el mismo directorio con git me parece mucho más cómodo, ya que no tengo que volver a configurar Apache y reiniciar. y no arruino mi sistema de archivos cada vez que hago una bifurcación.

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

La razón por la que muchos usuarios de Hg prefieren clones a ramas 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 de los conjuntos de cambios de forma recursiva.

Por otro lado, git invita a utilizar "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 ligado al concepto de ramas nombradas y de cambio entre una rama y otra dentro del mismo directorio;hg puede hacer lo mismo con ramas con nombre, pero aun así fomenta el uso de clones, lo que personalmente no me gusta demasiado.

Hay uno enorme diferencia entre git y mercurial;la forma en que representan cada compromiso. git representa confirmaciones como instantáneas, mientras que mercurial los representa como diferencias.

¿Qué significa esto en la práctica?Bueno, muchas operaciones son más rápidas en git, como cambiar a otra confirmación, comparar confirmaciones, etc.Especialmente si estos compromisos están lejos.

AFAIK, el enfoque de Mercurial no tiene ninguna ventaja.

Nada.Ambos hacen lo mismo, ambos se desempeñan aproximadamente por igual.La única razón por la que deberías elegir uno sobre el otro es si ayudas con un proyecto que ya utiliza uno.

La otra posible razón para elegir uno es una aplicación o servicio que solo admite uno de los sistemas.Por ejemplo, prácticamente elegí aprender git debido a github..

También la comparación de Google (aunque es un poco antigua, hecha en 2008)

http://code.google.com/p/support/wiki/DVCSAnalysis

Si los entiendo correctamente (y estoy lejos de ser un experto en cada uno), fundamentalmente cada uno tiene una filosofía diferente.La primera vez que usé mercurial fue durante 9 meses.Ahora he usado git por 6.

hg es un software de control de versiones.Su objetivo principal es realizar un seguimiento de las versiones de un software.

git es un sistema de archivos basado en el tiempo.Su objetivo es agregar otra dimensión a un sistema de archivos.La mayoría tiene archivos y carpetas, git agrega tiempo.El hecho de que funcione de maravilla como VCS es un subproducto de su diseño.

En hg, hay un historial de todo el proyecto que siempre intenta mantener.De forma predeterminada, creo que hg quiere que todos los usuarios realicen todos los cambios en todos los objetos al empujar y tirar.

En git solo hay un grupo de objetos y estos archivos de seguimiento (ramas/cabezas) que determinan qué conjunto de esos objetos representan el árbol de archivos en un estado particular.Al empujar o tirar, git solo envía los objetos necesarios para las ramas particulares que estás empujando o tirando, que es un pequeño subconjunto de todos los objetos.

En lo que respecta a git, no existe "1 proyecto".Podrías tener 50 proyectos todos en el mismo repositorio y a git no le importaría.Cada uno podría administrarse por separado en el mismo repositorio y funcionar bien.

El concepto de sucursales de Hg es sucursales del proyecto principal o sucursales de sucursales, etc.Git no tiene tal concepto.Una rama en git es solo un estado del árbol, todo es una rama en git.Qué rama es oficial, actual o más nueva no tiene significado en git.

No sé si eso tuvo algún sentido.Si pudiera hacer dibujos, hg podría verse así, donde cada confirmación es un o

             o---o---o
            /        
o---o---o---o---o---o---o---o
         \         /
          o---o---o

Un árbol con una sola raíz y ramas que salen de ella.Si bien git puede hacer eso y, a menudo, la gente lo usa de esa manera, eso no se aplica.Una imagen de git, si existe tal cosa, fácilmente podría verse así

o---o---o---o---o

o---o---o---o
         \
          o---o

o---o---o---o

De hecho, en algunos aspectos ni siquiera tiene sentido mostrar ramas en git.

Una cosa que es muy confusa para la discusión es que git y mercurial tienen algo llamado "rama", pero no son ni remotamente lo mismo.Una rama en mercurial surge cuando hay conflictos entre diferentes repositorios.Una rama en git es aparentemente similar a un clon en hg.Pero un clon, si bien puede dar un comportamiento similar, definitivamente no es lo mismo.Considere probarlos en git vs hg usando el repositorio de chromium, que es bastante grande.

$ time git checkout -b some-new-branch
Switched to new branch 'some-new-branch'

real   0m1.759s
user   0m1.596s
sys    0m0.144s

Y ahora en hg usando clon

$ 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

Ambas son carreras calientes.Es decir, los ejecuté dos veces y esta es la segunda ejecución.hg clone es en realidad lo mismo que git-new-workdir.Ambos crean un directorio de trabajo completamente nuevo casi como si hubieras escrito cp -r project project-clone.Eso no es lo mismo que crear una nueva rama en git.Pesa mucho más.Si existe un verdadero equivalente de la ramificación de git en hg, no sé cuál es.

Entiendo en algún nivel hg y git podría poder hacer cosas similares.Si es así, todavía hay una gran diferencia en el flujo de trabajo al que te llevan.En git, el flujo de trabajo típico es crear una rama para cada característica. 

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

Eso acaba de crear 3 ramas, cada una basada en una rama llamada maestra.(Estoy seguro de que hay alguna manera en git de hacer esas 1 línea cada una en lugar de 2)

Ahora para trabajar en uno solo lo hago

git checkout fix-game-save-bug

y empezar a trabajar.Cometer cosas, etc.Cambiar entre ramas incluso en un proyecto tan grande como Chrome es casi instantáneo.En realidad no sé cómo hacer eso en hg.No forma parte de ningún tutorial que haya leído.

Otra gran diferencia.El escenario de Git.

Git tiene esta idea de un escenario.Puedes considerarlo como una carpeta oculta.Cuando te comprometes, solo confirmas lo que está en el escenario, no los cambios en tu árbol de trabajo.Puede que suene extraño.Si desea confirmar todos los cambios en su árbol de trabajo, haría git commit -a que agrega todos los archivos modificados al escenario y luego los confirma.

¿Cuál es el objetivo de la etapa entonces?Puede separar fácilmente sus confirmaciones.Imagina que editaste joypad.cpp y gamesave.cpp y quieres enviarlos por separado.

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 incluso tiene comandos para decidir qué líneas particulares del mismo archivo desea copiar al escenario para poder dividir esas confirmaciones por separado también.¿Por qué querrías hacer eso?Porque como confirmaciones separadas, otros pueden extraer solo las que quieran o, si hubo un problema, pueden revertir solo la confirmación que tuvo el problema.

Hay un cuadro de comparación dinámica en el blog de control de versiones donde puede comparar varios sistemas de control de versiones diferentes.

Aquí hay una tabla de comparación entre git, hg y bzr.

Existen diferencias bastante significativas a la hora de trabajar con sucursales (especialmente las de corta duración).

Se explica en este artículo (Explicación de la ramificación) que compara Mercurial con Git.

¿Hay algún colaborador basado en Windows en su proyecto?

Porque si las hay, la GUI de Git para Windows parece incómoda, difícil y poco amigable.

Mercurial-on-Windows, por el contrario, es una obviedad.

Una cosa a tener en cuenta entre mercurial de bitbucket.org y git de github es que mercurial puede tener tantos repositorios privados como desee, pero en github debe actualizar a una cuenta paga.Por eso elijo bitbucket, que usa mercurial.

En algún momento del año pasado evalué tanto git como hg para mi propio uso y decidí utilizar hg.Sentí que parecía una solución más limpia y funcionó mejor en más plataformas en ese momento.Aunque fue más que nada una voltereta.

Más recientemente, comencé a usar git debido a git-svn y la capacidad de actuar como cliente de Subversion.Esto me convenció y ahora me cambié completamente a git.Creo que tiene una curva de aprendizaje un poco más alta (especialmente si necesitas hurgar en el interior), pero realmente es un gran sistema.Voy a leer esos dos artículos comparativos que John publicó ahora.

Actualmente estoy en el proceso de migrar de SVN a DVCS (mientras escribo en un blog sobre mis hallazgos, mi primer esfuerzo real en un blog...), y he investigado un poco (=buscando en Google).Por lo que puedo ver, puedes hacer la mayoría de las cosas con ambos paquetes.Parece que git tiene algunas características avanzadas más o mejor implementadas, Siento que la integración con Windows es un poco mejor para mercurial, con TortoiseHg.Sé que también existe Git Cheetah (probé ambos), pero la solución mercurial parece más sólida.

Al ver que ambos son de código abierto (¿verdad?), no creo que a ninguno le falten características importantes.Si algo es importante, la gente lo pedirá, lo codificará.

Creo que para prácticas comunes, Git y Mercurial son más que suficientes.Ambos tienen grandes proyectos que los utilizan (Git -> Linux Kernel, Mercurial -> Mozilla Foundation Projects, ambos entre otros, por supuesto), así que no creo que a ninguno de los dos les falte algo.

Dicho esto, me interesa lo que otras personas digan sobre esto, ya que sería una gran fuente para mis esfuerzos de blog ;-)

Hay tablas y gráficos comparativos excelentes y exhaustivos en git, Mercurial y Bazaar en Guía de InfoQ sobre DVCS.

Me doy cuenta de que esto no es parte de la respuesta, pero en ese sentido, también creo que la disponibilidad de complementos estables para plataformas como NetBeans y Eclipse influyen en qué herramienta se adapta mejor a la tarea, o más bien, qué herramienta. es la mejor opción para "usted".Es decir, a menos que usted en realidad Quiero hacerlo a través de CLI.

Tanto Eclipse (y todo lo basado en él) como NetBeans a veces tienen problemas con sistemas de archivos remotos (como SSH) y actualizaciones externas de archivos;que es otra razón más por la que quieres que todo lo que elijas funcione "sin problemas".

También estoy tratando de responder esta pregunta por mí mismo ahora mismo.y he reducido los candidatos a Git o Mercurial.Gracias a todos por brindar aportes útiles sobre este tema sin volverse religiosos.

Otra comparación interesante más de mercurial y git: Mercurial y Git.La atención se centra principalmente en los aspectos internos y su influencia en el proceso de ramificación.

Si está interesado en una comparación de rendimiento de Mercurial y Git, eche un vistazo a Este artículo.La conclusión es:

Git y Mercurial obtienen buenos resultados, pero hacen un equilibrio interesante entre velocidad y tamaño del repositorio.Mercurial es rápido tanto con adiciones como con modificaciones, y al mismo tiempo mantiene bajo control el crecimiento del repositorio.Git también es rápido, pero su repositorio crece muy rápidamente con archivos modificados hasta que lo vuelves a empaquetar, y esos reempaquetados pueden ser muy lentos.Pero el repositorio lleno es mucho más pequeño que el de Mercurial.

El sitio web mercurial tiene un Gran descripción de las similitudes y diferencias. entre los dos sistemas, explicando las diferencias de vocabulario y conceptos subyacentes.Como usuario de git desde hace mucho tiempo, realmente me ayudó a comprender la mentalidad de Mercurial.

Si está migrando desde SVN, use Mercurial ya que su sintaxis es MUCHO más comprensible para los usuarios de SVN.Aparte de eso, tampoco puedes equivocarte.Pero comprueba tutorial de git y HGinit antes de seleccionar uno de ellos.

Este enlace puede ayudarle a comprender la diferencia.http://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/

Algunas personas piensan que los sistemas VCS tienen que ser complicados.Fomentan la invención de términos y conceptos en el campo.Probablemente pensarían que serían interesantes numerosos doctorados sobre el tema.Entre ellos probablemente se encuentran los que diseñaron Git.

Mercurial está diseñado con una mentalidad diferente.Los desarrolladores no deberían preocuparse mucho por VCS y, en cambio, deberían dedicar su tiempo a su función principal:Ingeniería de software.Mercurial permite a los usuarios usar y abusar felizmente del sistema sin permitirles cometer errores irrecuperables.

Cualquier herramienta profesional debe venir con una CLI intuitiva y claramente diseñada.Los usuarios de Mercurial pueden hacer la mayor parte del trabajo emitiendo comandos simples sin opciones extrañas.En Git double dash, las opciones locas son la norma.Mercurial tiene una ventaja sustancial si eres una persona de CLI (y, para ser honesto, cualquier ingeniero de software que se precie debería serlo).

Para dar un ejemplo, supongamos que realiza un compromiso por error.Olvidaste editar algunos archivos.Para deshacer tu acción en Mercurial simplemente escribe:

$ hg rollback

Luego recibirá un mensaje indicando que el sistema deshace su última transacción.

En Git tienes que escribir:

$ git reset --soft HEAD^

Bueno, supongamos que tienes una idea de qué se trata el reinicio.Pero además tienes que saber qué son los reinicios "--soft" y "--hard" (¿alguna suposición intuitiva?).¡Ah, y por supuesto no olvides el carácter '^' al final!(Ahora, en nombre de Ritchie, ¿qué es eso...?)

La integración de Mercurial con herramientas de terceros como kdiff3 y meld también es mucho mejor.Genera tus parches y fusiona tus ramas sin mucho problema.Mercurial también incluye un servidor http simple que se activa escribiendo

hg serve

Y deja que otros naveguen por tu repositorio.

La conclusión es que Git hace lo que hace Mercurial, de una manera mucho más complicada y con una CLI muy inferior.Utilice Git si desea convertir el VCS de su proyecto en un campo de investigación científica.Utilice Mercurial si desea realizar el trabajo de VCS sin preocuparse mucho y concentrarse en sus tareas reales.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top