He estado usando git durante algún tiempo en Windows (con msysGit) y me gusta la idea del control de fuente distribuida. Recientemente he estado 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.
Respuestas:
Estos artículos pueden ayudar:
Editar : Comparar Git y Mercurial con las celebridades parece ser una tendencia. Aquí hay uno más:
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 conforman la historia. Cada conjunto de cambios sabe de dónde proviene (el conjunto de cambios principal) y puede tener muchos conjuntos de cambios secundarios. El reciente extensión hg-git proporciona un puente bidireccional entre Mercurial y Git y muestra este punto.
Git tiene un fuerte enfoque en mutar este gráfico de historia (con todas las consecuencias que conlleva), mientras que Mercurial no fomenta la reescritura de la historia, pero de todos modos es fácil hacerlo y las consecuencias de hacerlo son exactamente lo que debe esperar que sean (eso es , si modifico un conjunto de cambios que ya tiene, su cliente lo verá como nuevo si lo retira de mí). Entonces Mercurial tiene un sesgo hacia los comandos no destructivos.
En cuanto a las ramas ligeras, Mercurial ha admitido repositorios con múltiples ramas desde ..., siempre creo. Los repositorios de Git con múltiples ramas son exactamente eso: múltiples hilos de desarrollo divergentes en un solo repositorio. Git luego agrega nombres a estos hilos y le permite consultar estos nombres de forma remota. La extensión Marcadores para Mercurial agrega nombres locales, y con Mercurial 1.6, puede mover estos marcadores cuando presiona / tira.
Uso Linux, pero aparentemente TortoiseHg es más rápido y mejor que el equivalente de Git en Windows (debido al mejor uso del pobre sistema de archivos de Windows). Tanto http://github.com como http://bitbucket.org proporcionan 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. Intenta echar un vistazo al git-instaweb.sharchivo si quieres saber a qué me refiero: es un script de shell que genera un script de Ruby , 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 , por si acaso.
Me gusta la publicación del blog que compara 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 cómo cada sistema hace lo que Linus describió como "¡la fusión más genial NUNCA!" . En Git puede fusionarse 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 se ven bastante arcanas a mis ojos. 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 el --forceindicador hg pull, que es necesario ya que Mercurial abortará de lo contrario cuando extraiga de un repositorio no relacionado. Son diferencias como esta las que hacen que Mercurial me parezca más elegante.
git pull <url-of-project>. el correo que citó es de los primeros días de git (2005)
Git es una plataforma, Mercurial es "solo" una aplicación. Git es una plataforma de sistema de archivos versionada que se entrega 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 duros que las aplicaciones enfocadas. Pero esto también significa que el VCS de git es inmensamente flexible, y hay una gran profundidad de cosas sin control de fuente que puede hacer con git.
Esa es la esencia de la diferencia.
Git se entiende mejor desde cero, desde el formato del repositorio hacia arriba. Git Talk de Scott Chacon es una excelente introducción para esto. Si intentas usar git sin saber lo que sucede debajo del capó, terminarás confundido en algún momento (a menos que te limites a una funcionalidad muy básica). Esto puede sonar estúpido cuando todo lo que quieres es un DVCS para tu rutina de programación diaria, pero el genio de git es que el formato del repositorio es realmente muy simple y puedes entender toda la operación de git con bastante facilidad.
Para algunas comparaciones más orientadas al tecnicismo, los mejores artículos que he visto personalmente son los de Dustin Sallings:
En realidad, ha usado ambos DVCS ampliamente y los comprende bien a ambos, y terminó prefiriendo git.
La gran diferencia está en Windows. Mercurial es compatible de forma nativa, Git no. Puede obtener un alojamiento muy similar a github.com con bitbucket.org (en realidad, incluso mejor, ya que obtiene un repositorio privado gratuito). Estuve usando msysGit por un tiempo, pero me mudé a Mercurial y estuve muy contento con él.
Si usted es un desarrollador de Windows que busca un control básico de revisión desconectado, 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.
Creo que la mejor descripción sobre "Mercurial vs. Git" es:
Son casi idénticos La diferencia más importante, desde mi punto de vista (es decir, la razón 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 clone el repositorio en otro directorio y comience a desarrollar. Entonces, tiras y te unes. Con git, debe dar un nombre explícito a la nueva rama de tema que desea usar, luego comienza a codificar usando el mismo directorio .
En resumen, cada rama en Mercurial necesita su propio directorio; en git usualmente trabajas en un solo directorio. Cambiar 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 dado que generalmente trabajo en proyectos web, usar siempre el mismo directorio con git me parece muy cómodo, ya que no tengo que volver -configura Apache y lo reinicio y no ensucio mi sistema de archivos cada vez que ramifico.
Editar: como señaló Deestan, Hg ha nombrado ramas , que se pueden almacenar en un único repositorio y permiten al desarrollador cambiar ramas dentro de la misma copia de trabajo. Las ramas de git no son exactamente lo mismo que las ramas con nombre de 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 alienta a usar clones para tareas experimentales de ejecución corta y ramas con nombre para tareas de ejecución prolongada, como las ramas de lanzamiento.
La razón por la cual muchos usuarios de Hg prefieren los clones sobre la rama nombrada 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 de forma recursiva los metadatos 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 cambia entre una rama y otra dentro del mismo directorio; hg puede hacer lo mismo con ramas con nombre, pero alienta el uso de clones, que personalmente no me gustan demasiado.
Hay una gran diferencia entre git y mercurial ; la forma en que representan cada commit. git representa confirmaciones como instantáneas, mientras que mercurial las 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 estas confirmaciones están muy lejos.
AFAIK no hay ninguna ventaja del enfoque de mercurial.
Nada. Ambos hacen lo mismo, ambos realizan casi por igual. La única razón por la que debe elegir uno sobre el otro es si ayuda con un proyecto que ya usa uno.
La otra posible razón para elegir uno es una aplicación o servicio que solo es compatible con uno del sistema. Por ejemplo, elegí aprender git debido a github .
También la comparación de Google (aunque es un poco vieja, hecha en 2008)
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 para 6.
hg es un software de control de versiones. Su objetivo principal es rastrear las versiones de una pieza de 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 increíblemente como VCS es un subproducto de su diseño.
En hg, hay una historia de todo el proyecto que siempre intenta mantener. Por defecto, creo que hg quiere todos los cambios en todos los objetos por parte de todos los usuarios 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. Cuando empuja o tira, git solo envía los objetos necesarios para las ramas particulares que empuja o tira, que es un pequeño subconjunto de todos los objetos.
En lo que respecta a git, no hay un "1 proyecto". Podrías tener 50 proyectos en el mismo repositorio y a git no le importaría. Cada uno podría gestionarse por separado en el mismo repositorio y vivir bien.
El concepto de sucursales de Hg es ramificaciones del proyecto principal o ramificaciones de sucursales, etc. Git no tiene ese 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 reciente no tiene significado en git.
No sé si eso tenía sentido. Si pudiera dibujar imágenes, hg podría verse así donde cada commit es uno
o---o---o
/
o---o---o---o---o---o---o---o
\ /
o---o---o
Un árbol con una sola raíz y ramas saliendo de él. Si bien git puede hacer eso y, a menudo, las personas lo usan de esa manera, eso no se aplica. Una imagen de git, si existe, podría verse fácilmente así
o---o---o---o---o
o---o---o---o
\
o---o
o---o---o---o
De hecho, de alguna manera ni siquiera tiene sentido mostrar ramas en git.
Una cosa que es muy confusa para la discusión, git y mercurial tienen algo llamado "rama" pero no son remotamente las mismas cosas. Se produce una rama en mercurial cuando hay conflictos entre diferentes repositorios. Una rama en git es aparentemente similar a un clon en hg. Pero un clon, aunque podría dar un comportamiento similar, definitivamente no es lo mismo. Considéreme probar estos en git vs hg usando el repositorio de cromo 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 carrera. hg clone es lo mismo que git-new-workdir. Ambos crean un directorio de trabajo completamente nuevo casi como si hubieras escritocp -r project project-clone . Eso no es lo mismo que hacer una nueva rama en git. Es mucho más pesado. Si hay un verdadero equivalente de la ramificación de git en hg, no sé qué es.
Entiendo que, en algún nivel, hg y git podrían hacer cosas similares. Si es así, todavía hay una gran diferencia en el flujo de trabajo al que lo 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 master. (Estoy seguro de que hay alguna forma en git para hacer esas 1 línea cada una en lugar de 2)
Ahora para trabajar en uno solo hago
git checkout fix-game-save-bug
y empezar a trabajar Cometer cosas, etc. Cambiar entre ramas incluso en un proyecto tan grande como el cromo es casi instantáneo. En realidad no sé cómo hacer eso en hg. No es parte de ningún tutorial que haya leído.
Otra gran diferencia. El escenario de Git.
Git tiene esta idea de un escenario. Puedes pensarlo como una carpeta oculta. Cuando se compromete, solo se compromete lo que está en el escenario, no los cambios en su árbol de trabajo. Eso puede sonar extraño. Si desea confirmar todos los cambios en su árbol de trabajo, haría lo git commit -aque agrega todos los archivos modificados a la etapa y luego los confirma.
¿Cuál es el punto del escenario entonces? Puedes separar fácilmente tus commits. Imagina que editaste joypad.cpp y gamesave.cpp y quieres comprometerlos 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 en el mismo archivo que desea copiar en el escenario para que también pueda dividir esas confirmaciones por separado. ¿Por qué querrías hacer eso? Porque como confirmaciones separadas, otros pueden obtener solo las que desean o, si hubo un problema, pueden revertir solo la confirmación que tuvo el problema.
git add --patchvea linux.die.net/man/1/git-add o use git add -i, como en stackoverflow.com/questions/2372583/…
checkout -b <name>usted, podría usarlo git branch <name>para crear una nueva rama sin cambiar a ella
Hay una tabla de comparación dinámica en el blog control de versiones donde puede comparar varios sistemas de control de versiones diferentes.
dir-a/foo.c de dir-b/foo.cy seguir trabajando en dir-b/foo.c, entonces su trabajo sobre dir-a/foo.cse fusionarán correctamente con mi trabajo después de un tirón.
Existen diferencias bastante significativas cuando se trata de trabajar con sucursales (especialmente las de corto plazo).
Se explica en este artículo (BranchingExplained) que compara Mercurial con Git.
¿Hay algún colaborador basado en Windows en su proyecto?
Porque si los hay, la GUI de Git-for-Windows parece incómoda, difícil y hostil.
Mercurial-on-Windows, por el contrario, es obvio.
En algún momento del año pasado evalué git y hg para mi propio uso, y decidí ir con hg. Sentí que parecía una solución más limpia, y funcionó mejor en más plataformas en ese momento. Sin embargo, fue principalmente una sacudida.
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 he cambiado completamente a git. Creo que tiene una curva de aprendizaje un poco más alta (especialmente si necesita hurgar por dentro), pero realmente es un gran sistema. Voy a leer esos dos artículos de comparación que John publicó ahora.
Actualmente estoy en el proceso de migrar de SVN a un DVCS (mientras blogueo sobre mis hallazgos, mi primer esfuerzo real de blogging ...), y he investigado un poco (= googlear). Hasta donde 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, creo que la integración con Windows es un poco mejor para mercurial, con TortoiseHg. Sé que también está Git Cheetah (probé ambos), pero la solución mercurial simplemente se siente más robusta.
Al ver cómo ambos son de código abierto (¿verdad?) No creo que ninguno carezca de características importantes. Si algo es importante, la gente lo pedirá, lo codificará.
Creo que para las prácticas comunes, Git y Mercurial son más que suficientes. Ambos tienen grandes proyectos que los usan (Git -> kernel de Linux, Mercurial -> proyectos de la fundación Mozilla, ambos, por supuesto), por lo que no creo que a ninguno les falte algo.
Dicho esto, estoy interesado en lo que otras personas dicen sobre esto, ya que sería una gran fuente para mis esfuerzos de blogging ;-)
Hay una gran y exhaustiva comparación de tablas y gráficos en git, Mercurial y Bazaar en la 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 desempeña un papel en qué herramienta se adapta mejor a la tarea, o mejor dicho, qué herramienta es la mejor opción para "usted". Es decir, a menos que realmente quieras hacerlo a la CLI.
Tanto Eclipse (y todo lo que se base en él) como NetBeans a veces tienen problemas con los sistemas de archivos remotos (como SSH) y las actualizaciones externas de archivos; lo cual es otra razón por la que desea que lo que elija funcione "sin problemas".
Estoy tratando de responder esta pregunta por mí mismo ahora mismo ... y he resumido a los candidatos a Git o Mercurial ... gracias a todos por brindar aportes útiles sobre este tema sin volverme religioso.
Otra comparación interesante de mercurial y git: Mercurial vs Git . El enfoque principal está en lo interno 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 números, pero hacen una compensación interesante entre la velocidad y el tamaño del repositorio. Mercurial es rápido con adiciones y modificaciones, y mantiene el crecimiento del repositorio bajo control al mismo tiempo. Git también es rápido, pero su repositorio crece muy rápidamente con archivos modificados hasta que vuelve a empaquetar, y esos reempaques pueden ser muy lentos. Pero el repositorio empaquetado es mucho más pequeño que el de Mercurial.
El sitio web mercurial tiene una excelente 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 revise el tutorial de GIT y HGinit antes de seleccionar uno de ellos.
Este enlace puede ayudarlo 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. Animan a inventar términos y conceptos en el campo. Probablemente pensarían que numerosos doctorados sobre el tema serían interesantes. Entre ellos están probablemente los que diseñaron Git.
Mercurial está diseñado con una mentalidad diferente. Los desarrolladores no deberían preocuparse mucho por VCS, y deberían dedicar su tiempo a su función principal: la ingeniería de software. Mercurial permite a los usuarios usar y abusar felizmente del sistema sin permitirles cometer errores no recuperables.
Cualquier herramienta profesional debe venir con una CLI claramente diseñada e intuitiva. Los usuarios de Mercurial pueden hacer la mayor parte del trabajo emitiendo comandos simples sin ninguna opción extraña. En Git double dash, las opciones locas son la norma. Mercurial tiene una ventaja sustancial si usted es una persona de CLI (y para ser honesto, cualquier ingeniero de software respetuoso debería serlo).
Para dar un ejemplo, suponga que comete un error por error. Olvidaste editar algunos archivos. Para deshacer su acción en Mercurial, simplemente escriba:
$ hg rollback
Luego recibe un mensaje de que el sistema deshace su última transacción.
En Git tienes que escribir:
$ git reset --soft HEAD^
Entonces, supongamos que tiene una idea de qué se trata el restablecimiento Pero además, debe saber qué son los reinicios "--soft" y "--hard" (¿alguna suposición intuitiva?). ¡Ah, y por supuesto, no olvides el carácter '^' al final! (ahora lo que en nombre de Ritchie es que ...)
La integración de Mercurial con herramientas de terceros como kdiff3 y meld también es mucho mejor. Genera tus parches fusiona tus ramas sin mucho alboroto. Mercurial también incluye un servidor http simple que se activa escribiendo
hg serve
Y deje que otros naveguen por su repositorio.
La conclusión es que Git hace lo que hace Mercurial, de una manera mucho más complicada y con un CLI muy inferior. Use Git si desea convertir el VCS de su proyecto en un campo de investigación científica. Use Mercurial si desea realizar el trabajo de VCS sin preocuparse mucho por eso, y concéntrese en sus tareas reales.