popularidad de Git/Mercurial/bazar frente a la cual recomendar

Question

A juzgar por el número de preguntas en este sitio para estos tres sistemas de control de versiones distribuidos, parece que Git ya sea

1. es más popular, o
2. es más difícil (por lo tanto, requiere más preguntas), o
3. tiene más funciones (por lo tanto, requiere más preguntas).

O muy probablemente una combinación de los tres. (Digamos que la popularidad de este sitio equivale a la popularidad en general.) Aquí están los números:

 
       | Jun 2009 | Jul 2010 | Jul 2011 | Jul 2012 | Jul 2013 | Jul 2014 | Jul 2015 | Jul 2016 | Jun 2017 
    --------------------------------------------------------------------------------------------------------------- 
    [svn]  |  2353 |  5323 |  9028 | 12687 | 15587 | 18846 | 21209 | 23037 | 24692 
    [git]  |  726 |  3725 |  9225 | 17523 | 27862 | 41478 | 55315 | 71056 | 86958 
    [mercurial] |  169 |  1120 |  2765 |  4221 |  5230 |  6030 |  6651 |  7134 |  7524 
    [bazaar] |  50 |  159 |  252 |  351 |  425 |  483 |  506 |  525 |  534 

no es del todo satisfactoria tener tres aún compitiendo productos de código abierto en gran medida equivalentes a elegir. Personalmente utilizo Git y estoy bien con los otros dos. Pero cuando se trata de recomendar un sistema sobre los otros, me gustaría preguntar: ¿podemos comenzar a recomendar uno con seguridad todavía?

Comentarios de mediados de 2009: La popularidad histórica reciente de Subversion se refleja claramente en el número de preguntas, lo que indica al menos una pequeña inclinación de la balanza hacia Git sobre el Mercurial o Bazaar.

Comentarios desde mediados de 2010: Observe ese enorme aumento relativo en los números de Mercurial. Obviamente, solo dos puntos de datos no son suficientes para mostrar una tendencia, pero parece que Git y Subversion están muy atrincherados, Mercurial ha experimentado un gran crecimiento y Bazaar se ha mantenido relativamente tranquilo.

Breve comentario, mediados de 2011: ¿Podemos simplemente llamar a Git el ganador? :) No, acepto el argumento de que el número de preguntas no es equivalente a la popularidad. Sin embargo, los números son fuertes.

Answer 1

actualización de noviembre de 2011:

Git es ahora mucho más maduro en comparación con 2009:

• smart http ahora es compatible, lo que significa que puede ofrecer a su protocolo https cliente para tirar/clon y empujar, con autenticación capaz de interactuar con un LDAP (importante para el usuario en una empresa)
• Ahora existe una capa de autorización madura con Gitolite, lo que significa que puede proporcionar aislamiento para el repositorio "confidencial" (agai n, importante para grandes empresas).
apoyo
• las ventanas, que ya estaba allí en 2009, es todavía fuerte, y TortoiseGit es bastante estable
• La integración con el IDE como Eclipse está en curso (la mayoría de los proyectos de Eclipse están ahora en GitHub)

sin embargo, instalar Git en un entorno centralizado no es trivial:
Ver "Distributed Version Control Systems and the Enterprise - a Good mix?"

---

un punto fallado consistentemente es:

son diferentes en su naturaleza.

• SVN es un sistema REVISIÓN (que almacena rama y etiqueta a través única copia barata! Merge apoyo no es muy eficiente), y es centralizada.
• Mercurial o bazar son VCS ARCHIVO (que almacenan las versiones de los archivos ), y distribuidos.
  Arne Babenhauserheide lo enmienda para Mercurial señalando History model, con "archivo, manifiesto y conjunto de cambios".
• Git, y eso es muy difícil de entender, es un (delta se almacena de contenido, no el archivo en sí: dos archivos con el mismo contenido se almacenan sólo una vez) CONTENT VCS

Eso significa :

• si tiene un simple , en un solo lugar el desarrollo, se adhieren con SVN
• si tiene varios lugares de desarrollo, un VC distribuido S es más adecuado.
• si tiene un complex merge workflow, cualquier VCS moderno es mejor que SVN, que tiene dificultades para mantener la información de fusión en los lugares correctos durante años. Luego depende de las herramientas (Mercurial tiene un soporte de Windows más avanzado, por ejemplo)
• si tiene principalmente archivos de texto y archivos binarios no demasiado grandes, Git es excelente, siempre que tenga conocimiento de its limits.

Answer 2

Bueno, la razón por la que git tiene tantos usuarios es que el kernel de Linux lo usa, así que si quieres hacer un desarrollo de Linux, usas git.

Dado que mucha gente está involucrada con git, yo recomendaría usar git, simplemente debido a la base de usuarios más grande. De hecho, los números que muestra arriba son una clara señal de esto.

En cuanto a la dificultad, es difícil controlar todas las versiones, especialmente las distribuidas. SVN y CVS no fueron exactamente fáciles (al menos para mí) a primera vista. Esto es solo parte de la curva de aprendizaje necesaria para acostumbrarse a un sistema de control de versiones.

EDITAR: Desde que agregó una referencia de subversión, calculé que lo abordaría. Creo que la mayoría de la gente usará svn porque tiene todo tipo de interfaces guapas para él. En general, las personas odian usar la línea de comando, incluidos algunos desarrolladores. git generalmente tampoco funciona muy bien en Windows (o al menos no tan a la perfección). Dado que muchas personas están en Windows, esto elimina la cantidad de usuarios potenciales.

Además, creo que los conceptos de SVN son un poco más fáciles de comprender ya que svn usa un repositorio central en lugar de un sistema distribuido. Es más fácil entender, "Aquí está la gran montaña de código, por favor agregue su código aquí", que "Aquí hay un código, el mío podría ser diferente al suyo, el suyo, pero puede agregar algo si lo desea."

En mi opinión, svn tiene un sistema de documentación mucho mejor configurado. La documentación de git apunta a un nivel de conocimiento un poco más alto (del programa, no de la inteligencia de un programador) y tiene sentido después de usar el sistema, pero cuando se inicia por primera vez, parece un montón de gobbeldy-gook.

En general, creo que svn es y siempre será más frecuente porque sus conceptos generales de operación son más fáciles de entender, las herramientas son fáciles de usar y tiene un soporte maravilloso en Windows.

Déjeme terminar con mis dos centavos finales y decir que prefiero git porque creo que es mucho más poderoso que cualquier otro sistema que yo ' ve usado. Escalar la curva de aprendizaje definitivamente vale la pena una vez que comienzas a entender mejor el programa.

Answer 3

Desde el origen de la codificación social con Git en GitHub, Git parece haber atraído a muchos seguidores.

Answer 4

Una interesante blog post de Eric Sink sobre todas ellas.

Answer 5

yo uso y recomiendo mercurial

• en lugar de la subversión, ya que apoya el desarrollo distribuido. Puedo trabajar en varias máquinas y comprometerme localmente. No se puede hacer esto con subversión, al menos no sin saltos mortales como repositorios adicionales
• en lugar de bazar porque el soporte de windows de bazar es ... bueno.
• en lugar de git, ya que es a) más fácil de aprender y utilizar, y b) el apoyo de Windows es mucho mejor

Answer 6

[NOTA: Con el lanzamiento de Subversion 1.7, el primer párrafo de mi respuesta a continuación está fuera de fecha, ya que Subversion ahora solo crea una sola carpeta ".svn" en la carpeta base, similar a las otras ahora.]

Una de las ventajas de cualquiera de las tres subversiones es que no crea un equivalente de una carpeta ".svn" en cada carpeta del proyecto. Usualmente solo tiene uno (".hg", ".bzr" o ".git") en la carpeta base. Solo eso puede ser una buena razón para usar uno de ellos a través de svn incluso si está utilizando un modelo de repositorio centralizado. (Aparte: de hecho, a menudo uso svk como mi cliente svn cuando uso un repositorio svn solo para esta característica (solo linux, svk no es bueno en Windows)).

Por supuesto, una ventaja de la subversión es que no es necesario que desprotege todo el proyecto si solo necesita una de sus subcarpetas.

Answer 7

A juzgar por el número de preguntas en este sitio para estos tres sistemas de control de versiones distribuidos, parece que Git ya sea

1. es más popular, o
2. es más difícil (por lo tanto, requiere más preguntas), o
3. tiene más características (por lo tanto, requiere más preguntas).

1. Acerca de SMC popularidad - véase la siguiente pregunta StackOverflow: Are there any popularity/usage statistics available for the Free RCS/SCM/VCS systems?. Aquí tenemos preguntas como qué conjunto de archivos ignorar usar para un tipo específico de proyecto, que son independientes de SCM, pero se les pide Git (y usar la etiqueta 'git'), porque es la persona que hizo el uso de la pregunta.

2. Sobre Git siendo más difícil (y por lo tanto tiene más preguntas sobre el SO) - sin duda Git tiene curva de aprendizaje. También utiliza pocos conceptos (bastante) únicos, como el área de ensayo (el índice), o todas las ramas son iguales, que son responsables de su poder, pero puede ser difícil hacerlo bien al principio (especialmente si uno proviene de otro SCM) . Además, la interfaz de usuario de Git no es completamente uniforme (aunque mejora), porque se cultivó en lugar de desarrollarse; que es responsable de su potencia, pero puede conducir a una interfaz de usuario que no es óptima.

3. Sobre Git tener más características - que tendría que comprobar cuántos SO preguntas se refieren a características avanzadas/infrecuente de Git. Sin embargo, debe tener en cuenta que los proyectos de fuente abierta toman ideas entre sí, o tienen características similares desarrolladas independientemente: un ejemplo sería encontrar errores bisectando (buscando) la historia de la confirmación que introdujo el error que (hasta donde yo sé) desarrollado primero en Git, y luego implementado como complemento en Bazar, y primera extensión y funcionalidad principal actual en Mercurial. Otro sería interactivo seleccionando fragmentos de cambios para comprometer, inspirados por el comportamiento de Darcs. Otra sería la idea del paquete de Git, tomada de un concepto similar en Mercurial.

4. Sin embargo, otra posibilidad de fuente de mayor número de SO pregunta podría ser falta de una buena documentación ... aunque hoy en día se pone mejor con Git User's Manual (distribuido con Git) y Git Community Book (que se encuentra en la página principal de Git). Todavía existe este meme persistente que Git tiene peor documentación que, por ejemplo, la subversión con su Version Control with Subversion (también conocidos como svnbook) y Mercurial: The Definitive Guide (también conocido como hg-libro) ... y la gente no lee la documentación antes de preguntar pregunta sobre StackOverflow, a veces.

No es del todo satisfactoria tener tres aún compitiendo productos de código abierto en gran medida equivalentes a elegir. Personalmente utilizo Git y estoy bien con los otros dos. Pero cuando se trata de recomendar un sistema sobre los otros, me gustaría preguntar: ¿podemos comenzar a recomendar uno con seguridad todavía?

Bueno, Git y Mercurial se desarrollaron de forma independiente a partir de las casi al mismo tiempo en la respuesta de la terminación de la licencia libre para BitKeeper para su uso por los desarrolladores del kernel de Linux, como un sustituto del mismo. Subversion estaba fuera de cuestión como SCM centralizado, con falta de soporte (entonces) en el núcleo para el seguimiento de fusión; esto lo hizo completamente inadecuado para el modelo de desarrollo ampliamente distribuido del kernel de Linux. Bazar probablemente era demasiado lento (al menos entonces), y un poco centralizado (supongo).

Git es más potente (en mi opinión), Mercurial es más simple (en opinión de las personas) y un poco más portátil (Python); Git es programable y está basado en un modelo de datos que permite reimplementaciones independientes (por ejemplo, JGit, git escrito en Java), mientras que Mercurial tiene enlaces de Python para escribir extensiones, y se basa principalmente en API que permite el cambio de formato de repositorio subyacente (revlog - revlog-ng) ... pero esa es solo mi suposición. Llenan nichos ligeramente diferentes.

Además, ¿no se considera una buena opción? Tenemos KDE y tenemos GNOME y XFCE (y otros administradores de ventanas y entornos de escritorio); tenemos Emacs y Vim (y otros editores de programadores); tenemos distribuciones basadas en rpm (por ejemplo, Fedora Core, Mandriva, SuSE) y basadas en deb (Debian, Ubuntu) y basadas en tgz (Slackware) y basadas en fuente (Gentoo); tenemos KWord, AbiWord y OpenOffice.org ... y tenemos Git, Mercurial y Bazaar.

Answer 8

En mi experiencia, a juzgar por el número de preguntas, se obvia la comparación con git y Mercurial. La razón es doble:

1. Tenga una mirada en hg update --help frente git checkout -h y git --help checkout. Con Mercurial rara vez encuentro preguntas que no responden algunas miradas de ayuda.

2. http://mercurial-scm.org/wiki - si necesita ayuda, es probable que la encuentras ahí, incluyendo muchos Tipps y trucos: http://mercurial-scm.org/wiki/TipsAndTricks

Answer 9

Canonical (Ubuntu) canciones software package usage para su distribución, así que no hay necesidad de confiar en el problema de Stack Exchange cuenta para medir la popularidad. Sin embargo, como han señalado otros, esto solo hace un seguimiento de los usuarios de Ubuntu y utiliza Canonical (Ubuntu) y recomienda bzr (sesgo de muestra). Sin embargo ...

  2011 2011 2011   
Package  Aug 3 Sep 29 Dec 9 Change 
------  ------ ------ ------ ------ 
git-core 3647 3402 3236 -11% 
bzr   4975 5286 6070 +22% 
mercurial 3411 3387 3461  +1% 

El descenso de votos para el paquete git-core me hace pensar que he hecho algo mal como grep ed el nombre del paquete equivocado de la mesa de popularidad ubuntu. O tal vez incluso este conteo de "votos" está relacionado con las instalaciones y no con el uso real del software.

Aquí hay algunos datos históricos para la tendencia. Utilicé las estadísticas <install> en lugar de <vote> de Ubuntu en esta tabla, pero muestra un crecimiento acelerado en Bazar y Mercurial a partir de 2011. No obstante, bzr estuvo detrás de git en 2011, pero las estadísticas recientes de 2011 muestran que pasó git en total instancias instaladas (en Ubuntu).

 June Aug  Dec  Growth Oct Growth 
     2010 2011 2011   2013 
---- ----- ---- ---- ------ ---- ------ 
git  94k 159k 171k  80% 165k -3.5% 
bzr  52k 121k 135k  160% 170k 26.0% 
hg  36k  68k  75k  110% 95k 26.7% 

Discalaimer: Solía ​​bzr en Ubuntu hasta 2012 cuando trabajaba en los equipos que utilizan exclusivamente git. Bzr funciona bien con todas las demás VCS, lo que le permite utilizar una sintaxis de línea de comandos bzr consistente e intuitiva. Mi cambio al git fue por razones sociales más que técnicas.

Answer 10

Compruebe el siguiente enlace a una encuesta sobre el tema:

http://www.debian-administration.org/polls/160

Answer 11

Normalmente no publicar, pero ..

He intentado git, bzr y algunos otros que me olvide y found bzr tiene un punto muy muy débil. Para archivos grandes, insiste en cargar todo el archivo en la memoria. Esto crea problemas para grandes binarios.

Git fue mucho mejor en ese sentido. En cuanto a la dificultad Yo uso git en windows desde el git bash. Funciona muy bien y se aprendió en menos de una semana (eso incluía el trabajo real y la experimentación con otros VCS)