130 votos

Popularidad de Git/Mercurial/Bazar vs que recomendar

Van por el número de preguntas en esta página para estas tres distribuido sistemas de control de versiones, parece que Git sea

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

O más probablemente una combinación de los tres. (Vamos a decir que la popularidad de este sitio equivale a la popularidad en grande). Aquí están los números:

 | Junio 2009 | Julio 2010 | Julio 2011 | Julio 2012
-------------------------------------------------------
 [svn] | 2353 | 5323 | 9028 | 12687
 [git] | 726 | 3725 | 9225 | 17523
 [mercurial] | 169 | 1120 | 2765 | 4221
 [bazar] | 50 | 159 | 252 | 351

No es del todo satisfactorio tener tres competir sin embargo, en gran medida equivalentes productos de código abierto para elegir. Personalmente yo uso Git y estoy bien con los otros dos. Pero cuando se trata de recomendar un sistema sobre el otro, me gustaría preguntarle: ¿podemos empezar a recomendar con seguridad todavía?

Comentarios a partir de mediados de 2009: El histórico reciente popularidad de Subversion está claramente reflejada por el número de preguntas, indicando, al menos, una pequeña inclinación de la balanza hacia el Git sobre el Mercurial o Bazaar.

Comentarios a partir de mediados de 2010: Mira que el enorme incremento relativo en la Mercurial números. Obviamente sólo dos puntos de datos no son suficientes para mostrar una tendencia, pero se ve como Git y Subversion son en gran parte afianzada, Mercurial ha visto un gran crecimiento, y el Bazar se ha mantenido relativamente tranquilo.

Breve comentario, a mediados del 2011: ¿Se puede llamar a Git el ganador? :) No, acepto el argumento de que el número de preguntas no es equivalente a la popularidad. Los números de seguro son fuertes, aunque.

113voto

VonC Puntos 414372

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 usted puede ofrecer a su cliente de protocolo https para tirar/clon y empuje, con autenticación capaz de interactuar con un servidor de LDAP (importante para el usuario en una empresa)
  • Una madura de capa de autorización que ahora existe con Gitolite, lo que significa que usted puede proporcionar aislamiento para "confidencial" repositorio (de nuevo, importante para las grandes empresas).
  • El soporte de Windows que ya estaba allí, en 2009, todavía va 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, la instalación de Git en un entorno centralizado no es trivial:
Consulte "Control de versiones Distribuido y Sistemas de la Empresa - una Buena mezcla?"


Un punto consistentemente perderse:

son diferentes en su naturaleza.

  • SVN es un sistema de REVISIÓN (tiendas de rama y etiqueta a través de la copia barata! Combinación de soporte no es muy eficiente), y está centralizado.
  • Mercurial o bazaar ARCHIVO VCS (almacén de versiones de archivos), y distribuido.
    Arne Babenhauserheide modifica para que Mercurial señalando la Historia del modelo, con "archivo de manifiesto y de cambios".
  • Git, y que es muy difícil de comprender, es un CONTENIDO VCS (tiendas delta de contenido, no el archivo en sí: dos archivos con el mismo contenido se almacena sólo una vez)

Eso significa que:

  • si usted tiene una simple combinación de flujo de trabajo, en una sola ubicación de desarrollo palo, con SVN
  • si usted tiene varios lugares desarrollo, y se distribuye a VCS es la más adecuada.
  • si usted tiene un complejo de mezcla de flujo de trabajo, las VCS es mejor que la SVN que lucha para mantener la combinación de información en los lugares adecuados para años. Entonces depende de las herramientas (Mercurial tiene un más avanzado de soporte técnico de Windows por ejemplo)
  • si usted tiene principalmente archivo de texto y no demasiado grandes archivos binarios, Git es excelente, siempre y cuando usted es consciente de sus límites.

46voto

Jakub Narębski Puntos 87537

Van por el número de preguntas en esta página para estas tres distribuido sistemas de control de versiones, parece que Git sea

  1. es más popular, o
  2. es más difícil (por lo tanto, se requieren más preguntas), o
  3. tiene más características (por lo tanto, se requieren más preguntas).
  1. Acerca de SCM popularidad , consulte la siguiente StackOverflow pregunta: ¿hay alguna popularidad / el uso de las estadísticas disponibles para el Libre RCS/SCM/VCS sistemas?. Aquí tenemos a preguntas como ¿qué conjunto de ignorar los archivos a utilizar para cada tipo de proyecto, que son SCM agnóstico, pero se les pide a Git (y el uso de 'git' tag), porque es lo que la persona que hizo la pregunta de su uso.

  2. Acerca de Git ser más difícil (y por lo tanto tener más preguntas acerca de sobre MANERA) -- ciertamente, Git tiene empinada curva de aprendizaje. También utiliza unos pocos (muy) conceptos únicos, como el área de ensayo (el índice), o todas las ramas de ser iguales, el cual es responsable de su poder, pero podría ser difícil de conseguir al principio (sobre todo si uno viene de otro SCM). También Git interfaz de usuario no es completamente consistente (aunque se pone mejor), porque fue crecido más que los desarrollados; que es responsable de su poder, pero podría conducir a subóptima de la interfaz de usuario.

  3. Acerca de Git tener más funciones -- usted tendrá que comprobar cómo muchas de las preguntas son acerca de advanced / infrecuente características de Git. Usted debe ser consciente, sin embargo, que los proyectos de código abierto prestado ideas de uno y otro, o tienen características similares, desarrollado de forma independiente: un ejemplo sería la búsqueda de errores dividiendo (búsqueda) de la historia por cometer, que introdujo el error que fue (que yo sepa) desarrollado por primera vez en Git, y, a continuación, implementado como plugin en el Bazar, y la primera prórroga y en la actualidad núcleo de la funcionalidad en Mercurial. Otro sería interactivo, selección de fragmentos de los cambios a cometer, inspirado por Darcs comportamiento. Sin embargo, otra sería Git paquete idea, tomada de concepto similar en Mercurial.

  4. Sin embargo, otra posibilidad de fuente de mayor número de LO que se pregunta podría ser la falta de una buena documentación... a pesar de que hoy en día se pone mejor con Git Manual del Usuario (distribuido con Git) y Git de la Comunidad de Libro (que se encuentra en Git página de inicio). Todavía hay esta persistente meme que Git tiene peor documentación que, por ejemplo, a la Subversión con su Control de versiones con Subversion (también conocido como svnbook) y Mercurial: La Guía Definitiva (también conocido como hg-libro)... y la gente no lea la documentación antes de efectuar la pregunta en StackOverflow, a veces.

No es del todo satisfactorio tener tres competir sin embargo, en gran medida equivalentes productos de código abierto para elegir. Personalmente yo uso Git y estoy bien con los otros dos. Pero cuando se trata de recomendar un sistema sobre el otro, me gustaría preguntarle: ¿podemos empezar a recomendar con seguridad todavía?

Bien, Git y Mercurial fueron desarrollados de forma independiente, comenzando en casi el mismo tiempo en la respuesta de la terminación de la licencia gratuita para BitKeeper para su uso por parte de desarrolladores del núcleo Linux, como un reemplazo para él. La subversión estaba fuera de la cuestión centralizado SCM, con la falta de apoyo (a continuación) en el núcleo de mezcla de seguimiento; este hecho es completamente inadecuado para el ampliamente distribuida modelo de desarrollo del kernel de Linux. Bazar fue probablemente demasiado lento (al menos entonces), y un poco centralizadas lado (supongo).

Git es más potente (en mi opinión), Mercurial es simple (en opinión de gente) y un poco más portable (Python); Git es de secuencias de comandos y se basa en el modelo de datos que permite independiente reimplementations (véase, p. ej. JGit, git escrito en Java), mientras Mercurial ha enlaces Python para escribir extensiones, y se basa en gran medida en la API que permite el cambio de formato de repositorio (revlog - revlog-ng)... pero eso es sólo mi suposición. Rellena ligeramente diferentes nichos.

Además de no tener una opción que se considera bueno? Tenemos KDE y tenemos GNOME y XFCE (y otros gestores de ventanas y escritorio envirionments); hemos de Emacs y Vim (y otros del programador editores); la hemos basado en rpm (p. ej. Fedora Core, Mandriva, SuSE) y deb (Debian, Ubuntu) y tgz (Slackware) y basada en el código fuente (Gentoo) distribuciones; hemos KWord, AbiWord y OpenOffice.org... y tenemos Git, Mercurial y Bazaar.

20voto

Rad Puntos 6308

Yo uso y recomiendo mercurial

  • en lugar de subversión porque apoya desarrollo distribuido. Puedo trabajar en varias máquinas y cometer localmente. No puedes hacer esto con la subversión, al menos no sin saltos mortales como repositorios adicionales
  • en lugar de Bazar como soporte de windows del Bazar es... bueno.
  • en lugar de git porque es un) más fácil de aprender y apoyo uso y b) de windows es mucho mejor

14voto

Evan Puntos 9261

[NOTA: Con la versión de Subversion 1.7, en el primer párrafo de mi respuesta a continuación es fuera de fecha, como la Subversión ahora sólo crea un único ".svn" carpeta en la carpeta base, similar a la de los otros ahora.]

Una de las ventajas de cualquiera de los tres más de subversion es que no crea un equivalente de un ".svn" carpeta en cada carpeta del proyecto. Normalmente sólo tiene uno (".hg", ".bzr" o ".git") en la carpeta base. Eso solo puede ser una buena razón para usar uno de ellos a través de svn, incluso si usted está usando un repositorio centralizado modelo. (Aparte: De hecho, yo uso a menudo svk como mi cliente de svn cuando se utiliza un repositorio svn sólo para esta función (sólo para linux, aunque, svk no es bueno en windows).

Por supuesto, una de las ventajas de subversion es que no tienes de ver el proyecto entero si sólo tiene uno de sus sub-carpetas.

14voto

En mi experiencia, a juzgar por el número de preguntas notablemente sesga la comparación a git y en contra de Mercurial. El motivo es doble:

  1. Eche un vistazo a hg update --help versus git checkout -h y git --help checkout. Con Mercurial yo raramente encontrado preguntas que no son contestadas por un par de miradas a hg ayuda.

  2. http://mercurial.selenic.com/wiki - si usted necesita ayuda, usted probablemente encontrará allí, incluyendo a muchos Tips y Trucos: http://mercurial.selenic.com/wiki/TipsAndTricks

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X