¿Por qué Git recibió tanta exageración? ... mientras que otros no lo hacen? [cerrado]

Creo que servicios como enlace o enlace Es un factor importante. Es importante para las personas que puedan alojar sus cosas en algún lugar, y especialmente github es un gran servicio para eso.

Para mercurial, no hubo tal servicio cuando dvcs se hizo popular (al menos ninguno que yo conocía). Tiene enlace ahora y probablemente otros, pero github ha estado allí durante bastante tiempo, es bien conocido y mejora y mejora.

Veo muchas respuestas a esto que se basan en los sentimientos que el autor tuvo al escuchar acerca de uno u otro SCM. Otros dicen que todo fue pura suerte. Creo que la suerte se remonta a la historia.

Hablaré de historia.

Git y Mercurial se crearon simultáneamente para resolver el mismo problema. En aquellos días, el kernel de Linux se vio obligado a salir de un período en el que había estado utilizando BitKeeper , un SCM distribuido de propiedad que les había servido durante muchos años.

De hecho, Larry McVoy, CEO de BitMover, la compañía detrás de BitKeeper, dejó de regalar su software de forma gratuita a los desarrolladores de Linux, porque alguien dentro de la comunidad de Linux tenía ingeniería inversa.

Linus Torvalds, insatisfecho con lo que ya existía, comenzó a trabajar en un nuevo SCM que pronto llamaría Git. Poco después, Matt Mackall comenzó el proyecto Mercurial por motivos similares.

Luego de un tiempo de desarrollo de estos proyectos por separado, Matt Mackall presentó una versión avanzada de su SCM y la evaluó de cierta manera, comparándola con Git (que solo tenía un par de semanas). Linus consideró usarlo en lugar de Git para el desarrollo de Kernel, pero abandonó la idea cuando se dio cuenta de que Mercurial estaba utilizando Changesets para registrar modificaciones de revisión . Temía que fuera demasiado parecido a la forma en que trabajaba BitKeeper, y ciertamente no quería nada que pudiera hacer que alguien dijera: "Ellos construyeron un clon de BitKeeper".

Por lo tanto, Git se usó para el desarrollo del Kernel en lugar de Mercurial, pero ambos eran técnicamente relevantes. El resultado final es que Git comenzó a utilizarse cuando se diseñó para ser utilizado, mientras que Mercurial no fue tan rápido en encontrar su primer gran uso de FOSS. Debido a que estaba dotado de un muy buen diseño, y gracias a la perseverancia de Matt Mackall, eventualmente se hizo famoso y se utilizó para grandes proyectos del mundo real.

Hoy, ambos son famosos. Es imposible decir cuál es el más famoso. Google Code solo integraba Git recientemente, mientras que tenía Mercurial durante mucho tiempo. Muchos proyectos realmente grandes y famosos usan cualquiera.

Supongo que lo que quiero decir es que, cuando la razón por la que has iniciado un proyecto se desvanece, es más difícil ganar popularidad, pero aún es factible.

Bazar es otro SCM que es muy famoso en el mundo de GNU, pero no tanto fuera de eso, porque se creó con la intención de satisfacer a la comunidad de GNU. El software a menudo va donde sus creadores quieren ir, y no más allá.

Por otro lado, los SCM distribuidos son claros ganadores. No veo muchos SCM no distribuidos ampliamente utilizados por ahí.

Linus Torvalds

Linus es un gran defensor de Git y lo promovió en gran medida al núcleo de Linux durante años y ha crecido a partir de ahí. Me atrevo a decir que se debe enteramente a la influencia de Linus sobre la comunidad * nix.

Personalmente, sigo usando Subversion, pero eso es de preferencia en lugar de utilidad.

El problema habitual con el sistema de control de versiones es fusionar ramas .

Debes haberlo probado cuando no funciona para comprender lo doloroso que puede ser y lo importante que es tenerlo para poder trabajar libremente con las sucursales.

Al enterarse de que Linus Torvalds escribió a git para hacer esto bien y que supuestamente en una situación él ha usado git para unir doce ramas a la vez, este es un argumento muy convincente para que git sea interesante. .

Estuve en la situación hace aproximadamente un año, donde tuve que elegir entre hg y git, y la fusión anterior fue un factor importante en la elección de git. La segunda fue que la organización Eclipse cambió a git, por lo que se esperaba que las herramientas de Eclipse fueran buenas para los proyectos Java. Con el lanzamiento de Eclipse 3.7 esto ha sucedido. Tal vez teníamos entre 6 y 9 meses de anticipación.

Para diferentes necesidades, hg puede ser igual de útil. Sun lo eligió para su VCS basándose en una investigación muy cuidadosa . Es posible que desee encontrar los libros blancos y ver cuáles fueron sus razonamientos.

EDIT: Nota, no estoy diciendo que haya algo que Mercurial no pueda hacer, solo eso para Java con Eclipse, que es nuestro enfoque principal, las fuerzas del mercado actualmente son más fuertes para git, incluso en Windows, y tenemos que estar de pie en los hombros de otros, no en sus pies.

En lugar de decir por qué git o mercurial es mejor y decir que es la única razón por la que es popular, me centraré en la comunidad.

Como yo resaltado anteriormente , la comunidad Git es muy ruidosa y arrogante. La mayoría defenderá vigorosamente su precioso programa. La mayoría de las guerras de Git y Mercurial que he visto fueron iniciadas por git personas que se preguntaban por qué todos en la Tierra no están usando el git sagrado. Sitios como whygitisbetterthanx.com incluso muestran esta arrogancia en la introducción, que está escrita para llama cebo otros.

No digo que todo el mundo sea de esta manera, pero la mayoría de las veces, cuando me he topado con gente de git, sitios web de pro-git y blogs de pro-git, sentí que git estaba siendo empujado por mi garganta en lugar de ser ofrecido como un sistema DVCS viable.

En contraste, otras comunidades DVCS no son tan ruidosas. No sabía que Mercurial existía hasta que vi un "¿Cuál es el mejor DVCS?" pregunta sobre SO. Mientras git aparece en todas partes, otros DVCS toman tiempo para encontrarlo.

No creo que Mercurial tenga un perfil particularmente bajo. El horno está construido en Hg & ha habido un buen soporte en IDE como Eclipse & Netbeans desde hace un tiempo.

La mayoría de los desarrolladores con los que hablo parecen preferir Hg debido al mejor soporte de Windows. Si fuéramos desarrolladores de Linux, podría ser una historia diferente.

También te estás perdiendo el "Bazar", que es el verdadero "DVCS olvidado".

Ciertamente estoy de acuerdo en que Linus es un tipo muy carismático y un nerd alfa casi sin igual, por lo que mucha gente gravitaría con Git por eso. Además, el "mito de la creación" de Git es muy convincente con Linus trabajando durante 6 días para crear Git y apoyarse en el séptimo, o algo así. Cuando un producto tiene una historia memorable, es más fácil ganar tracción.

Es una opinión humilde, pero git podría obtener todo este bombo debido a dos parámetros:

1. Es muy eficiente
2. Es divertido de usar (en algún tipo de método informático muy específico)

Además, git consiguió una aplicación excelente como github, y algunos proyectos muy populares decidieron usarla, lo que le dio mucha visibilidad.

Hay tres factores en juego aquí, "medios geek beta", "es el momento adecuado" y "seguir al líder"

Beta Geek Media

Hay una serie de canales que discuten las "actividades geek". Sin duda, cubrirían la apariencia de un nuevo sistema de control de versiones, pero cubrirían más git. ¿Por qué? Porque Linus Torvalds lo escribió inicialmente, lo discutió públicamente y lo usó como una solución a su problema bien publicitado con bitkeeper. Efectivamente, cada vez que hay una guerra de fuego en lkml, los medios beta geek escribirán un artículo al respecto. La discusión de Git comenzó en lkml, por lo que tuvo más cobertura que otras alternativas. Y los geeks beta que leen slashdot como si fuera Variety se lo comieron. El resultado final de eso es que git tiene diez veces más artículos que mercurial.

El tiempo es correcto

Los grandes proyectos de código abierto con muchos colaboradores tienen problemas con el control de fuente centralizado. A medida que crece el código abierto y es más probable que los proyectos tengan muchos colaboradores, el problema empeora. Linux es probablemente el proyecto más conocido que sufre esto, pero hay muchos otros. Con muchos proyectos llegando a este punto, se necesitaba algún tipo de VCS avanzado. Git, Mercurial y Bazaar fueron los grandes ganadores aquí. Arch y Monotone fueron demasiado pronto, y se perdió la ola de exageración.

Sigue al líder

Los grandes proyectos tienen seguidores que verifican y construyen el código regularmente, incluso si no contribuyen. Los seguidores se familiarizan con las herramientas necesarias para obtener el proyecto que siguen, por lo que esas herramientas se vuelven más útiles. Echemos un vistazo a los proyectos "big draw" para los tres grandes DVCS:

• Git : Linux, Perl, jQuery, Ruby on Rails, Eclipse, Gnome, KDE, QT, X
• Mercurial : Java, Mozilla, Python
• Bazar : Ubuntu, Emacs

Git tiene más proyectos "big draw" usándolo, por lo que más personas están familiarizadas con git, hay más tutoriales sobre git escritos.

Se trata principalmente de una exageración auto reforzada. Git es el más popular, por lo que recibe la mayor publicidad, lo que hace que se vuelva más popular.

Git, Hg y Bzr son sistemas DVCS perfectamente buenos, pero un número alarmante de personas equiparan a DVCS con Git, y piensan que todas las características encantadoras de un DVCS son exclusivas de Git. Y entonces usan Git, y recomiendan Git, y dicen cosas como "Git es mejor porque puede hacer una fusión de pulpos" (También puede Bazaar), o "Git es mejor porque está distribuido" (también lo es cualquier DVCS, de ahí el nombre), o "Git es mejor porque hace que la bifurcación y la fusión sean fáciles" (una vez más, esto es cierto para todos los DVCS).

Lamentablemente, porque creo que las alternativas también tienen mucho que ofrecer, y prefiero que la gente elija a Git por sus fortalezas únicas, antes que porque piensan que DVCS == Git.

Cuando alguien descubre qué tan inteligentes son los DVCS, al ser señalado a un DVCS específico, a menudo no van y le dicen a los demás "hey, los DVCS 'son geniales, deberías usarlos", sino "el DVCS que yo aprendí sobre DVCS es genial, deberías usarlo ".

Github. Github es un pionero en la codificación social. Convirtió el control de versiones en una plataforma social que atrajo mucha atención, y obviamente solo apoya a Git. Redes sociales = mayor adopción. Bitbucket está ganando fuerza a pesar de obtener muchas características nuevas, por lo que es un rival probable :)

Bueno, de hecho, creo que el bombo es sobre todas las reuniones de DSVC.

Pero los defensores de git son más vocales, a menudo más agresivos en sus comentarios para ser honestos y les gusta hablar de eso en todas partes.

Sospecho que Mercurial se usa ampliamente, ciertamente tan a menudo como git, tal vez más (Microsoft y otras grandes compañías lo usan ahora), pero la gente que usa Mercurial a menudo solo desea un DSVC que pueda captar rápidamente, no algo en lo que basarse. religión en Por lo tanto, son menos vocales y más reactivos en las discusiones que proactivos como algunos usuarios de git.

Bazaar no se habla mucho, sin duda, porque solo unos pocos grandes proyectos conocidos lo usan y no se sabe que ninguna otra gran empresa lo use Canonical. Compare con Google (git, mercurial, svn) y los grandes proyectos de código abierto, por ejemplo, y puede ver por qué no se habla realmente. Fossil es otro que es interesante para un nicho de desarrolladores, por lo que creo que es normal y correcto que solo lo escuchen aquellos que buscan las funciones que ofrecen (como wiki incorporado, seguimiento de problemas y foro).

Dicho esto, creo que estamos bajando lentamente el ciclo de exageraciones y muchos desarrolladores han usado varios Se pueden comenzar a ver diferentes soluciones que se ajustan a sus necesidades.

Además, Google Code Hosting y SourceForge ahora permiten git y mercurial, por lo que se está convirtiendo en una opción más específica del proyecto que antes cuando elegiste git debido a las características de GitHub.

No hay una guerra real, solo una interesante variedad de herramientas.

Sé que ya hay muchas respuestas a esta pregunta, pero sentí que podría agregar un poco más de perspectiva.

Usé Bazaar prácticamente desde que fue creado para varias cosas. Lo más importante para el que lo usé fue el proyecto AllTray, para el cual soy (actualmente) el único desarrollador y mantenedor. El bazar es bonito. Simplemente funciona, se mantiene fuera de mi camino, y casi nunca tengo que mirar una página de ayuda o la página de manual para ello. Dicho esto, hay algunos inconvenientes:

1. Una gran cantidad de funciones que tiene y que posiblemente deberían ser parte del núcleo VCS, no lo es. Cosas como la capacidad de realizar una bisección de la historia, ejecutar una salida larga a través de un buscapersonas o tener ramas "colocadas" (por ejemplo, repositorios de estilo git) se suministran como complementos.
2. Muchos de los complementos no son tan estables. Por ejemplo, la funcionalidad de las ramas colocadas no parece funcionar bien en el lado del servidor (al menos, nunca conseguí que funcionara, tiende a cometer errores al decir que la rama en la ruta dada no existe cuando está justo enfrente de ti y puedes ver la cosa sangrienta).
3. No tiene una operación de "clonación", usted tira de las ramas de una en una. Tienes que hacer un trabajo extra si quieres tener un repositorio para poder extraer nuevas sucursales de manera eficiente.
4. Para algunos proyectos, es doloroso lento. Pruebe "bzr branch lp: mysql" alguna vez.
5. Carece de soporte fuerte para ganchos; puede escribir complementos bzr que proporcionen enlaces, pero no hay una forma estándar de tener scripts de enlaces arbitrarios del lado del servidor.

Recientemente cambié a git para el desarrollo de AllTray, y estoy considerando muy rápidamente migrar todos mis proyectos a git. Hay un poco más de tiempo adelantado para conocer las cuerdas, pero parece que vale la pena. Algunas cosas que he notado:

1. git clone es una operación relativamente rápida y le brinda información sobre todas las sucursales que existen en el repositorio que clonó.
2. Agregar repositorios remotos adicionales es indoloro, por lo que puede hacer un seguimiento de muchos repositorios diferentes que tienen múltiples sucursales si lo desea.
3. El libro Pro Git está disponible en línea y en varios formatos, incluso para dispositivos de lectores de libros electrónicos, y no es una lectura difícil.
4. git parece mucho más fácil de extender que Bazaar, y no tienes que usar ninguna API en particular para hacerlo. (NB: esto es tanto una ventaja como una desventaja).
5. git tiene una bisección incorporada, y no puedo enfatizar lo suficiente la utilidad de esa función.
6. GitHub es bastante bueno.
7. El sistema gitosis también es bastante bueno. Ni siquiera estoy seguro de cómo se podría implementar eso de otra manera que no sea un complemento en Bazaar, y no puedo imaginar que fuera tan eficiente.

Breve historia corta: he usado bzr durante mucho tiempo, pero git está demostrando rápidamente su asombro.

Usando git, tiendes a permanecer siempre en el mismo directorio local cuando haces el desarrollo, y simplemente haces git checkout branchname para cambiar entre sucursales (uso ramas "ligeras" todo el tiempo, así que esta es una característica muy importante a mi).

Mirando la documentación y los tutoriales de Mercurial, parece que la manera preferida de tratar con diferentes ramas de desarrollo es crear nuevos repositorios mediante clonación. Este tutorial es un ejemplo.

Creo que puedes hacer lo mismo en Mercurial que en git, pero por alguna razón, la documentación de Mercurial (que he leído) casi siempre muestra ramificaciones al crear un clon de repositorio.

(Uso git a diario. Tengo poca experiencia con mercurial, he jugado con él y he seguido algunos tutoriales)

No sé cuántas de esas críticas he visto en las últimas semanas, pero todos parecen considerarlo como un hecho que Mercurial y / o Bazaar son objetivamente mejores que Git. La usabilidad parece ser un tema común. Sí, aprender Git fue sorprendentemente difícil después de usar CVS y Subversion, pero en este punto no me gustaría cambiarlo por ningún otro VCS a menos que constituyera otro cambio de paradigma . Y apuntar a una tabla de características me dirá muy poco acerca de cuán flexible, extensible, segura o sin esfuerzo es. Por ejemplo, de forma predeterminada git-diff usa colores y un paginador. Claro que puedo obtener lo mismo con diff ... | colordiff | less -R o algo así, pero debería ser obvio por qué uno es superior al otro.

Para ser justos, creo que los defensores de git contra mercurial son pocos y distantes entre sí en comparación con los defensores de git contra centralizados. Sin embargo, las razones son fáciles de resumir:

  

Git es el control de versiones para programadores. Mercurial es control de versiones.   para las empresas. Centralizado fue un primer intento adecuado de inventar   Control de versiones, especialmente considerando que fue diseñado antes del   revolución de la computadora personal.

Lo que quiero decir con control de versiones para los programadores es que, en general, los programadores favorecen la flexibilidad sobre la facilidad de aprendizaje. Después de todo, estamos dispuestos a pasar años aprendiendo idiomas esotéricos para tener la flexibilidad de hacer que las computadoras hagan lo que los no entrenados no pueden. Git les da a los programadores la flexibilidad de usarlo como les plazca, a costa de que le lleve más tiempo aprender a usar esa flexibilidad de manera segura. Permite que se implementen restricciones para hacer cumplir las políticas, pero no sale así de la caja. Tenga en cuenta que dije facilidad de aprender en lugar de facilidad de uso . Una vez que lo aprendes, git es tan fácil de usar como cualquier otro VCS, y a menudo es más fácil debido al aumento de la velocidad y las funciones.

Algunos programadores aprenden lo suficiente para hacer lo que quieren y luego se resisten a aprender nuevas formas de hacerlo. Las empresas contratan y emplean a muchas de estas personas, por lo que desean cualquier cambio en las herramientas que utilizan para tener un cierto grado de familiaridad. Las empresas también quieren que sus programadores tengan suficiente flexibilidad para hacer su trabajo, pero no tanto como para dificultar la capacitación o la migración inicial. Aquí es donde encaja Mercurial. Tiene la mayor parte del poder de git, pero es un camino de migración algo más sencillo.

No creo que sea justo decir que git solo es popular debido a las exageraciones o al respaldo de Linus. Es probable que eso explique a muchas personas que lo intenten , pero se mantienen y lo promocionan porque les funciona bien, puro y simple.

El desarrollo de NetBSD usa CVS y eso es todo lo que es importante.

Tiene un nombre más conciso y más conciso que se adapta bien a los juegos de palabras.

Hace poco estuve buscando un sistema de control de versiones para proyectos personales, así que probé varios. Soy prácticamente analfabeto en la línea de comandos, y había escuchado que, aunque las GUI estaban disponibles, Git estaba destinado a ser utilizado a través de la línea de comandos, lo que me hizo un poco indeciso. Honestamente, fue ridículamente fácil de aprender, y realmente lo estoy disfrutando. La documentación es un factor muy importante en la adopción de una nueva tecnología, y Git tiene toneladas de documentación ridículamente simple, clara y disponible. Las otras alternativas, como SVN y Bazaar, fueron geniales, simplemente no lo hicieron tan fácil como Git. Github también es un factor importante, ya que en este momento se ha convertido en algo central para el movimiento de código abierto. Tener una ubicación centralizada (irónicamente) para intercambiar código y proyectos es un cambio de juego en sí mismo.

Solo mis 2 ¢: elegí git sobre las alternativas porque está escrito en C en lugar de en un lenguaje de radtool o un lenguaje de alto nivel demasiado académico. Los beneficios son que es rápido y eficiente y que realmente puedo RTFS si encuentro errores o comportamientos que no puedo explicar. También hace posible su uso en pequeños entornos de desarrollo auto hospedados que no incluyen intérpretes / tiempos de ejecución gigantescos, lo que significa que puedo extraer directamente de un repositorio git y compilar en dichos sistemas en lugar de tener que buscar la última fuente en otro lugar y rsync. / p>     

Puede que te interese leer por qué el proyecto de escritorio GNOME eligió git sobre hg y bzr, cuando decidió pasar de svn algunos años atrás. Hubo muchas discusiones acaloradas en el camino, por supuesto, pero esta página de GNOME Wiki resume muy bien los pros y los contras según se aplican a eso. comunidad particular.

Sin mencionar que Apple ahora se ha involucrado en enviarlo a la comunidad objetivo c. Si recientemente ha creado una nueva aplicación en Xcode 4, se habría dado cuenta de que automáticamente le pregunta si desea hacer un Git. repo.

El Xcode 4 otorgado solo ha existido por algunos meses, y no influye en el éxito anterior de Gits, pero todos sabemos lo popular que Apple puede hacer las cosas en un corto espacio de tiempo.

Supongo que pura suerte, hasta ahora es casi imposible demostrar por qué algo funcionó y otros no. Linus puede construir algo más espectacular y no tener éxito.

Actualmente estoy cambiando de hg (horno) a git (github). He usado el horno durante aproximadamente un año en este momento. Para mí el hg no tiene inconveniente. Puedo hacer todo lo que tengo que hacer. Así que es genial.

¿Por qué estoy usando en este momento?

En este momento solo hay tres razones.

1. gitHub ofrece ideas que son geniales
2. gitHub ofrece excelentes funciones sociales
3. Mientras hago presentaciones y talleres para desarrolladores, siempre publico mis muestras en hg y git. ¡En git tengo aproximadamente 10 veces más visitantes que en hg!

Creo que el tercero es el más importante.

Thorsten