for español control git version-control mercurial comparison dvcs

español - ¿Cuál es la diferencia entre Mercurial y Git?



mercurial vs git (25)

He estado usando git desde hace algún tiempo en Windows (con msysGit) y me gusta la idea del control de código distribuido. Recientemente he estado mirando Mercurial (hg) y parece interesante. Sin embargo, no puedo comprender 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 saltar a una discusión de fanboy.

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

Porque si las hay, la interfaz gráfica de usuario de Git-para-Windows parece torpe, difícil y hostil.

Mercurial en Windows, por el contrario, es una obviedad.

Actualmente estoy en el proceso de migrar de SVN a un DVCS (mientras escribo sobre mis hallazgos, mi primer esfuerzo real de blogging ...), y he investigado un poco (= googlear). 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, creo que la integración con Windows es un poco mejor para mercurial, con TortoiseHg. Sé que también hay Git Cheetah (probé ambos), pero la solución mercurial se siente más robusta.

Viendo que ambos son de código abierto (¿verdad?) No creo que ninguno de los dos carezca de características importantes. Si algo es importante, la gente lo pedirá, la gente 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 -> linux kernel, Mercurial -> Mozilla foundation projects, ambos entre otros, por supuesto), así que no creo que ninguno de los dos realmente carezca de 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 ;-)

Algunas personas piensan que los sistemas VCS tienen que ser complicados. Alientan a inventar términos y conceptos en el campo. Probablemente pensarían que numerosos doctorados sobre el tema serían interesantes. Entre esos 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 un CLI claramente diseñado e intuitivo. 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 CLI (y para ser honesto, cualquier ingeniero de software que se precie debería serlo).

Para dar un ejemplo, supongamos que comete un error por error. Se te olvidó editar algunos archivos. Para deshacer tu acción en Mercurial simplemente escribe:

$ hg rollback

A continuación, recibe un mensaje de que el sistema deshace su última transacción.

En Git tienes que escribir:

$ git reset --soft HEAD^

Bien, supongamos que tienes una idea de qué se trata el reinicio. Pero además, tienes que saber qué se reinicia "--soft" y "--hard" (¿alguna conjetura 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. Genere sus parches fusione sus ramas sin mucho alboroto. Mercurial también incluye un servidor http simple que activa al escribir

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 hacer el trabajo de VCS sin preocuparse por eso, y enfóquese en sus tareas reales.

El sitio web de mercurial tiene una 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.

En algún momento del año pasado, evalué tanto git como 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 sobre todo un sorteo.

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 por completo a git. Creo que tiene una curva de aprendizaje ligeramente más alta (especialmente si necesitas meterte en el interior), pero realmente es un gran sistema. Voy a leer esos dos artículos de comparación que John publicó ahora.

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.

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 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 sin control de fuente que puedes hacer con git.

Esa es la esencia de la diferencia.

Git se entiende mejor desde el principio, desde el formato del repositorio hasta. Git Talk de Scott Chacon es un excelente manual para esto. Si intentas usar git sin saber qué está pasando debajo del capó, acabará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 la operación completa de git con bastante facilidad.

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

En realidad, ha utilizado ambos DVCS ampliamente y los entiende bien, y terminó prefiriendo git.

Hay una gran diferencia entre git y mercurial ; La forma en que representan cada uno se compromete. git representa confirmaciones como instantáneas, mientras que mercurial las representa como difs.

¿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 ventaja del enfoque de mercurial.

La gran diferencia está en Windows. Mercurial se apoya de forma nativa, Git no lo es. Puede obtener un alojamiento muy similar a github.com con bitbucket.org (en realidad, incluso mejor a medida que obtiene un repositorio privado gratuito). Estuve usando msysGit por un tiempo, pero me mudé a Mercurial y me sentí muy feliz con él.

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 juegan un papel en qué herramienta se adapta mejor a la tarea, o más bien, qué herramienta es el mejor ajuste para "usted". Es decir, a menos que realmente quieras hacerlo de la manera CLI.

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

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 proporcionar aportes útiles sobre este tema sin ser religiosos.

Nada. Ambos hacen lo mismo, ambos realizan aproximadamente 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 una es una aplicación o servicio que solo es compatible con uno de los sistemas. Por ejemplo, prácticamente elegí aprender git debido a github .

Otra comparación interesante de mercurial y git: Mercurial vs Git . El enfoque principal está 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 dan buenos números pero hacen un intercambio 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 los archivos modificados hasta que usted vuelve a empaquetar, y esos paquetes pueden ser muy lentos. Pero el repositorio empaquetado es mucho más pequeño que el de Mercurial.

Si está migrando de SVN, use Mercurial ya que su sintaxis es MUCHO más comprensible para los usuarios de SVN. Aparte de eso, no te puedes equivocar con ninguno de los dos. Pero revisa el tutorial GIT y HGinit antes de seleccionar uno de ellos.

Si los entiendo correctamente (y estoy lejos de ser un experto en cada uno) ellos tienen fundamentalmente una filosofía diferente. Utilicé mercurial por primera vez 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 tienen archivos y carpetas, git agrega tiempo. Que funcione como un VCS es un subproducto de su diseño.

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

En git solo hay un conjunto 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á empujando o tirando, que es un pequeño subconjunto de todos los objetos.

En lo que se refiere a git, no hay "1 proyecto". Podrías tener 50 proyectos en el mismo repositorio y a git no le importaría. Cada uno se puede administrar por separado en el mismo repositorio y en vivo bien.

El concepto de ramas de Hg es sucursales del proyecto principal o sucursales 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 tuvo algún sentido. Si pudiera dibujar imágenes, hg podría verse así, donde cada compromiso 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 él. Si bien git puede hacer eso y con frecuencia la gente lo usa de esa manera, eso no se aplica. Una imagen de git, si existe tal cosa, podría verse 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 que se llama "rama" pero no son remotamente las mismas cosas. Una rama en mercurial se produce cuando hay conflictos entre diferentes repos. 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 el mismo. Considérame probar esto 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

Ambos son carreras calientes. Es decir, los corrí dos veces y esta es la segunda carrera. hg clone es el 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 hacer una nueva sucursal 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 sucursales, cada una basada en una rama llamada master. (Estoy seguro de que hay alguna manera en git para hacer esas 1 líneas en lugar de 2)

Ahora para trabajar en uno acabo de hacer

git checkout fix-game-save-bug

y empieza a trabajar. Comprometa cosas, etc. El cambio entre sucursales incluso en un proyecto tan grande como Chrome es casi instantáneo. En realidad no sé cómo hacerlo 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 una etapa. 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. Eso puede sonar 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 punto de la etapa entonces? Usted puede separar fácilmente sus compromisos. Imagina que editaste joypad.cpp y gamesave.cpp y quieres cometerlos 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 en particular en el mismo archivo que desea copiar al escenario para que pueda dividir esas confirmaciones también por separado. ¿Por qué querrías hacer eso? Debido a que, como compromisos separados, otros solo pueden extraer los que quieren o si hubo un problema, pueden revertir solo el compromiso que tuvo el problema.

Si usted es un desarrollador de Windows que busca un control de revisión básico desconectado, vaya con Hg. Descubrí 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 más tarde, tuve un repositorio local y volví a trabajar en mi proyecto.

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 iniciar una nueva rama, con Mercurial, simplemente clonar el repositorio a otro directorio y comenzar a desarrollar. Entonces, tiras y te fundes. Con git, tiene que dar un nombre explícito a la nueva rama de tema que desea usar, luego comenzar a codificar usando el mismo directorio .

En resumen, cada sucursal en Mercurial necesita su propio directorio; en git usualmente trabajas en un directorio único. 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 a hacerlo. -Configure Apache y reinícielo y no desordené mi sistema de archivos cada vez que me bifurco.

Edición: Como señaló Deestan, Hg ha nombrado sucursales , que se pueden almacenar en un solo repositorio y permiten al desarrollador cambiar de sucursal dentro de la misma copia de trabajo. Las ramas de git no son exactamente iguales a las ramas con nombre de Mercurial, de todos modos: son permanentes y no tiran las ramas, como en git. Eso significa que si usa una rama con nombre para tareas experimentales, incluso si decide no fusionarla, se almacenará en el repositorio. Esa es la razón por la que Hg recomienda utilizar clones para tareas experimentales, de ejecución corta y sucursales con nombre para tareas de larga duración, como para liberar sucursales.

La razón por la que muchos usuarios de Hg prefieren los clones sobre las sucursales nombradas 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 sucursales con nombre y cambia entre una sucursal y otra dentro del mismo directorio; hg puede hacer lo mismo con las ramas con nombre, pero aún así fomenta el uso de clones, lo que personalmente no me gusta demasiado.

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 vino (el conjunto de cambios principal) y puede tener muchos conjuntos de cambios secundarios. La reciente extensión hg-git proporciona un puente bidireccional entre Mercurial y Git y en cierto modo muestra este punto.

Git tiene un fuerte enfoque en mutar este gráfico histórico (con todas las consecuencias que 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 debe esperar , si modifico un conjunto de cambios que ya tiene, su cliente lo verá como nuevo si lo saca de mí). Así que Mercurial tiene un sesgo hacia los comandos no destructivos.

En cuanto a las ramas ligeras, Mercurial ha admitido repositorios con múltiples sucursales desde ..., siempre pienso. Los repositorios de Git con múltiples ramas son exactamente eso: múltiples cadenas 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 de Bookmarks para Mercurial agrega nombres locales, y con Mercurial 1.6, puede mover estos marcadores cuando presiona / tira ...

Utilizo Linux, pero aparentemente 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). Tanto http://github.com como http://bitbucket.org proporcionan hospedaje en línea, el servicio en Bitbucket es excelente y sensible (no he probado github).

Elegí Mercurial porque se siente limpio y elegante. Me dejaron por los scripts de shell / Perl / Ruby que obtuve con Git. Intenta echar un vistazo al archivo git-instaweb.sh 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 de todas!" . En Git puedes fusionar con un repositorio no relacionado haciendo lo siguiente:

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 arcanos para mi ojo. 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 indicador de " --force a hg pull , que es necesario ya que Mercurial abortará de otro modo cuando extraiga de un repositorio no relacionado. Esas diferencias como esta hacen que Mercurial me parezca más elegante.

Una cosa a tener en cuenta entre mercurial de bitbucket.org y git of github es que mercurial puede tener tantos repositorios privados como quieras, pero github debes actualizar a una cuenta de pago. Entonces, es por eso que busco bitbucket que usa mercurial.