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


727

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:


345

Estos artículos pueden ayudar:

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


1
"Git vs Mercurial Please Relax" está muy desactualizado, aunque es tan antiguo como esta pregunta. Tal vez esta pregunta debería eliminarse y volver a abrirse ahora que ambas herramientas han agregado más de 3 años de funciones.
gman

238

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.


21
Tenga en cuenta que TortoiseHg también funciona junto con Nautilus, el administrador de archivos Gnome en Linux.
oenli

44
El script Ruby solo se genera si el httpd es Webrick, el servidor web ruby.
alternativa el

44
Al igual que Git, Mercurial almacena instantáneas de sus archivos cuando se compromete. No estoy de acuerdo en que los cambios de nombre solo se puedan rastrear con una heurística como en Git, no hay nada en el modelo que impida agregar información adicional a una instantánea, por ejemplo, cambiar el nombre de la información. Hacemos eso en Mercurial.
Martin Geisler

63
a un proyecto relacionado con git merge (pull), sólo tiene que hacer: git pull <url-of-project>. el correo que citó es de los primeros días de git (2005)
knittl

55
knittl: ah, bien, me alegra saber que Git se está volviendo menos arcano. Aún así, creo que el ejemplo muestra un poco cómo los sistemas difieren en lo que creemos que es genial y Git se siente más bajo para mí en comparación con Mercurial (pero no más poderoso).
Martin Geisler

73

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.


78
A menudo he leído que la gente menciona que git es una "plataforma", pero eso es más una teoría o un mito común porque no hay ejemplos importantes de ello como una plataforma para hacer algo más que ejecutar git.
Ian Kelling el

@ Ian: si no me equivoco, Aptana Studio 3 lo usa para su sistema de actualización interno.
mac

22
En pocas palabras: Mercurial es un sistema de control de revisión distribuido de código abierto, y git es una opción de estilo de vida.
Tim Keating

51

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.


64
Así que "nativamente" no es la palabra correcta, pero no es bien compatible con Windows, eso es seguro.
Ian Kelling el

14
git es compatible con un punto en Windows. Pero intente usar los nombres de archivo Unicode multiplataforma y vea qué dolor le produce.
Craig McQueen

@ Craig: Eso es más una deficiencia de la plataforma. Una plataforma competente le permitiría cambiar a una ubicación adecuada. Si te apegas a utf-8, estarás bien, excepto que Mac OS X tiene una normalización ligeramente diferente de utf-8, sin embargo, no estoy seguro de si Windows incluso te permite usar utf-8 ...
Arafangion

23
Windows admite Unicode, aunque MS eligió utilizar UTF-16 en su API en lugar de UTF-8. A pesar de eso, sería bastante posible que git sea compatible con la plataforma cruzada Unicode. SVN ha resuelto ese problema bastante bien. Pero no es una alta prioridad para el desarrollo de msysGit en este momento. code.google.com/p/msysgit/issues/detail?id=80
Craig McQueen

38

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.


1
Seguí el mismo tutorial. Es definitivo.
Nathan


20

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.


66
Esto no es una diferencia; Hg también ha nombrado ramas. Los usamos todo el tiempo durante el desarrollo normal en lugar de las ramas clónicas.
Deestan

2
AFAIK, la rama nombrada en Hg se obtienen almacenando metadatos en cada confirmación; Puedo estar equivocado, pero leí que una vez que crea una rama, sus metadatos se incrustarán en cada conjunto de cambios y pasarán a formar parte de la historia. Esta es una gran diferencia con git. "Los clones son excelentes para experimentos rápidos en los que no quieres grabar el nombre de una rama, y ​​las ramas con nombre son buenas para las ramas a largo plazo" tinyurl.com/2wz39qx Lo que estaba tratando de decir con mi publicación es que el flujo de trabajo estándar de git te invita usar una sola copia de trabajo; El flujo de trabajo estándar de Hg incluye clones, que no se ajustan a mis necesidades personales.
Arialdo Martini

Para una buena explicación de similitudes / diferencias con respecto a la ramificación en Git y Hg, consulte: mercurial.selenic.com/wiki/GitConcepts#Branch_model
sampablokuper

2
Las ramas con nombre en hg no se parecen en nada a las ramas en git. En hg, hay un camino verdadero . Todas las ramas son ramas fuera de ese camino. En git no hay un camino verdadero. Solo hay diferentes estados del repositorio y los punteros en ese estado. Cada rama es solo un puntero diferente. ¿Qué puntero es el principal? Las ramas son todas iguales.
gman

17

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.


29
La ventaja de los conjuntos de cambios (diffs) consiste en ocupar menos espacio. Git recupera el espacio utilizado para las confirmaciones mediante el uso de la compresión, pero esto requiere un paso ocasional de recompresión explícita ("git pack").
quark

8
Ahora se llama 'git gc', pero hay diferentes niveles de recolección de basura, y algunos niveles se ejecutan automáticamente en versiones recientes de git.
FelipeC

66
en realidad, mercurial también usa instantáneas
Ronny,

13
No entiendo la distinción que está haciendo entre 'instantáneas' y 'diffs'. Tanto hg como git store se comprometen como (grupos de) deltas de archivos . Esos deltas se basan en cualquier revisión previa que elija el SCM respectivo. ¿Tienes números que muestran que git es realmente más rápido para las operaciones que mencionaste? La actualización a otra confirmación pasa la mayor parte del tiempo escribiendo en el directorio de trabajo, no leyendo el repositorio, de todos modos.
Kevin

2
'Instantáneas versus' diferencias '- completamente irrelevante. Sin embargo, el repositorio almacenado internamente no tiene relación con lo que ve el usuario. Tanto git como mercurial presentan al usuario 'instantáneas'. No hay ninguna razón por la que un formato de repositorio implementado de la misma manera que git no pueda agregarse a mercurial, tal como creo que hizo Bazaar.
Mark Booth

11

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 .


66
Parece que tu respuesta fue demasiado pragmática. :)
Arafangion


11

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 incluso tiene comandos para decidir qué líneas en particular en el mismo archivo que quieres copiar en el escenario para que también puedas dividir esas confirmaciones por separado". ¿Cuáles son estos comandos?
James McMahon

1
@ James: git add --patchvea linux.die.net/man/1/git-add o use git add -i, como en stackoverflow.com/questions/2372583/…
tanascius

@gman: en lugar de revisar el maestro y ramificar con checkout -b <name>usted, podría usarlo git branch <name>para crear una nueva rama sin cambiar a ella
tanascius

8

Hay una tabla de comparación dinámica en el blog 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.


1
La información sobre Mercurial no es del todo precisa: Mercurial tiene "fusiones inteligentes después de movimientos o cambios de nombre". Concretamente, esto significa que si cambio el nombredir-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.
Martin Geisler

La información (proviene de la comparación de la Iniciativa Better SCM , IIRC) sobre Git también es inexacta o incluso no válida en algunos lugares.
Jakub Narębski


7

¿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.


Me gusta git, pero tengo que estar de acuerdo aquí. Git tiene una línea de comando más agradable con el escenario y una mejor documentación. Me encantaría usar los comandos git con un shell posix. Sin embargo, tortoiseHG en Windows es excelente, incluso se integra con varias herramientas diff (más allá de comparar) y tiene soporte completo para sub-repos, y muchos complementos hg como strip / mq
Keyo

Hay al menos una muy buena GUI de Windows (y OS X + Linux) Git disponible.
Mot

7

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


5

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.


44
Echa un vistazo a hgsubversion: bitbucket.org/durin42/hgsubversion . Actualmente requiere una versión de desarrollo de Mercurial, pero harán un lanzamiento para Mercurial 1.3, que vence el 1 de julio.
Martin Geisler

4

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 ;-)


1
Sí, ambos son proyectos de código abierto.
Martin Geisler


3

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.


2
+1, porque la experiencia "perfecta" es más importante de lo que piensan las personas que no trabajan con estas cosas. Un complemento sólido para el IDE hace una gran diferencia.
Eksortso

2

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.


2

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.



2

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.



1

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.


1
En realidad, puede alias comandos en git , lo que hace que la CLI sea menos complicada de usar. Hay un montón de ellos en esta pregunta SuperUser (StackExchange) .
Spoike

1
Realmente sí, también podría escribir scripts de shell para hacer frente a algunas tareas comunes. Eventualmente, comienza a darse cuenta de que está construyendo una CLI de contenedor para lidiar con un VCS que tiene una CLI mal diseñada y contra intuitiva. Y no es solo eso. Git presenta un montón de conceptos con usabilidad cuestionable que el usuario finalmente se ve obligado a aprender y comprender para sentirse cómodo con la documentación y los mensajes CLI.
Kostas
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.