¿Por qué Git se entusiasmó tanto? ... mientras que otros no? [cerrado]

En los últimos años, el entusiasmo por Git aumentó considerablemente. Todo el mundo sabe sobre Git, nadie sabe sobre alternativas.

Otros como Mercurial parecen pasar desapercibidos. Ambos se lanzaron en 2005 y ofrecen funcionalidades similares. Además, Mercurial generalmente se considera más fácil de usar, más intuitivo y tiene durante mucho tiempo mejores interfaces de usuario. Por lo tanto, se podría suponer que esta sería una alternativa popular, especialmente para aquellos nuevos en el control de versiones distribuido. Sin embargo, parece desconocido para la mayoría de la gente, a diferencia de Git, que tuvo bastante éxito.

El objetivo de esta publicación es intentar comprender mejor este fenómeno.

¿Cómo es que Git se hace parte del pastel? ¿Usaron de alguna manera un mejor marketing? ¿Es porque su comunidad es más ... ejem ... "detallada"? ¿Es por el nombre de "Linus"? ¿Es por su imagen geek?

¿Cual es tu opinion?

Creo que servicios como GitHub o Gitorious son 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 había tal servicio cuando DVCS se hizo popular (al menos ninguno que yo conociera). Ahora tiene Bitbucket y probablemente otros, pero GitHub ha estado allí durante bastante tiempo, es bien conocido y se pone cada vez mejor.

Veo muchas respuestas a esto que se basan en los sentimientos que tuvo el autor cuando escuchó sobre 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 dejar de usar BitKeeper , un SCM distribuido patentado que había estado usando durante 3 años. La razón de esto fue que Larry McVoy, CEO de BitMover, la compañía detrás de BitKeeper, dejó de entregar su software de forma gratuita a los desarrolladores de Linux, porque alguien dentro de la comunidad de Linux lo había modificado.

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

Después de algún tiempo desarrollando estos proyectos por separado, Matt Mackall presentó una versión avanzada de su SCM y lo comparó de cierta manera, comparándolo con Git (que en sí mismo tenía solo 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 usando Changesets para registrar modificaciones de revisión . Temía que eso estuviera demasiado cerca de la forma en que funcionaba BitKeeper, y ciertamente no quería nada que pudiera hacer que alguien dijera: "Construyeron un clon de BitKeeper".

Por lo tanto, Git se usó para el desarrollo de Kernel en lugar de Mercurial, pero ambos eran técnicamente relevantes. El resultado final es que Git comenzó siendo utilizado donde fue diseñado para usarse, mientras que Mercurial no fue tan rápido para 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. Cuál es el más famoso es imposible de decir. Google Code solo integró 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 ha comenzado un proyecto desaparece, es más difícil ganar popularidad, pero aún es factible.

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

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 grupo principal de Linux durante años y se ha desarrollado a partir de ahí. Me atrevo a decir que se debe completamente a la influencia de Linus sobre la comunidad * nix.

Personalmente sigo usando Subversion, pero eso es por preferencia y no por utilidad.

El punto de dolor habitual con el sistema de control de versiones es la fusión de ramas .

Debe haberlo intentado cuando no funciona para comprender lo doloroso que puede ser y lo importante que es trabajar, para poder trabajar libremente con las ramas.

Al enterarse de que Linus Torvalds escribió git para hacer esto bien, y que supuestamente en una situación ha usado git para fusionar 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 para elegir git. El segundo fue que la organización de Eclipse cambió a git, por lo que se esperaba que las herramientas de Eclipse fueran buenas para los proyectos de Java. Con el lanzamiento de Eclipse 3.7 esto ha sucedido. Estábamos quizás 6-9 meses antes de esto.

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

EDITAR: Tenga en cuenta que no estoy diciendo que Mercurial haya algo que no pueda hacer, solo eso para Java con Eclipse, que es nuestro enfoque principal, las fuerzas del mercado son actualmente más fuertes para git, incluso bajo Windows, y debemos apoyarnos. de otros, no 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 enfocaré en la comunidad.

Como destaqué anteriormente , la comunidad Git es muy ruidosa y arrogante. La mayoría defenderá vigorosamente su preciado programa. La mayoría de las guerras Git vs Mercurial que he visto fueron iniciadas por personas git 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 atraer a otros.

No digo que todo el mundo sea así, pero la mayoría de las veces, cuando me encuentro con personas git, sitios web pro-git y blogs pro-git, sentí que me estaban metiendo git en la garganta en lugar de ofrecerlo como un DVCS viable. sistema.

En contraste, otras comunidades de 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. Si bien git aparece en todas partes, otros DVCS tardan en encontrarlo.

No creo que Mercurial tenga un perfil particularmente bajo. Kiln está construido sobre Hg y ha habido un buen soporte en IDEs como Eclipse y Netbeans desde hace un tiempo.

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

También te estás perdiendo "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 a 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 descansando 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 toda esta exageración debido a dos parámetros:

1. Es muy eficiente
2. Es divertido de usar (de alguna manera muy específica en informática)

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

Aquí hay tres factores en juego: "beta geek media", "es el momento adecuado" y "sigue al líder"

Beta Geek Media

Hay varios canales que analizan las "actividades geek". Sin duda, cubrirían la apariencia de un nuevo sistema de control de versiones, pero cubren más. ¿Por qué? Debido a que Linus Torvalds lo escribió inicialmente, discutió sobre ello públicamente y lo usó como una solución a su bien publicitado problema con Bitkeeper. Efectivamente, cada vez que haya una guerra de llamas en lkml, los medios beta geek escribirán un artículo al respecto. La discusión de Git comenzó en lkml, por lo que obtuvo más cobertura que otras alternativas. Y los beta geeks 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 contribuyentes tienen problemas con el control de fuente centralizado. A medida que el código abierto crece y los proyectos se vuelven más propensos a tener muchos contribuyentes, el problema empeora. Linux es probablemente el proyecto más conocido que sufre de 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 llegaron demasiado pronto y se perdieron la ola de publicidad.

Sigue al líder

Los grandes proyectos tienen seguidores que revisan 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 tienen más uso. Echemos un vistazo a los proyectos de "gran atractivo" 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 de "gran atractivo" que lo utilizan, por lo tanto, más personas están familiarizadas con git, hay más tutoriales de git escritos.

Es principalmente solo un bombo autorreforzante. 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 aterrador de personas equipara DVCS con Git, y piensa 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 fusiones de pulpo" (también puede Bazaar), o "Git es mejor porque está distribuido" (así es cualquier DVCS, de ahí el nombre ), o "Git es mejor porque facilita la ramificación y la fusión" (nuevamente, esto es cierto para cada DVCS).

Lamentablemente, porque siento que las alternativas también tienen mucho que ofrecer, y prefiero que las personas elijan Git por sus fortalezas únicas, en lugar de simplemente porque piensan que DVCS == Git.

Cuando alguien descubre cuán inteligentes son los DVCS, al señalar un DVCS específico, a menudo no van y le dicen a los demás "oye, los DVCS son geniales, deberías usarlos", sino más bien "el DVCS que yo aprendí sobre DVCS de es genial, deberías usarlo ".

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

Bueno, de hecho, creo que la exageración se trata de todas las juntas DSVC.

Pero los defensores del 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 las personas que usan Mercurial con mayor frecuencia solo querían un DSVC que puedan captar rápidamente, no algo en lo que basar una religión. Por lo tanto, son menos vocales y más reactivos en las discusiones que proactivos, como algunos usuarios de git.

Ciertamente, no se habla mucho del bazar porque solo unos pocos grandes proyectos conocidos lo usan y no se sabe que otras grandes compañías que Canonical lo usen. Compare con Google (git, mercurial, svn) y 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 bueno que solo aquellos que buscan las funciones que brindan les escuchen (como wiki incorporado, seguimiento de problemas y foro).

Dicho esto, creo que estamos bajando lentamente el ciclo de exageración y muchos desarrolladores que han usado varias soluciones diferentes pueden comenzar a ver cuál se ajusta a sus necesidades.

Además, Google Code Hosting y SourceForge ahora permiten tanto git como mercurial, por lo que se está convirtiendo en una opción más específica para el proyecto que antes cuando elegía 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é Bazar casi desde que fue creado para varias cosas. Lo más importante para lo que lo utilicé fue el proyecto AllTray, del cual soy (actualmente) el único desarrollador y mantenedor. El bazar es lindo. 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. Dicho esto, hay algunas desventajas:

1. Tiene mucha funcionalidad que posiblemente debería ser parte del VCS central, no lo es. Cosas como la capacidad de realizar una bisección de la historia, ejecutar una salida larga a través de un localizador 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 ramas ubicadas no parece funcionar bien en el lado del servidor (al menos, nunca lo hice funcionar, tiende a equivocarse diciendo que la rama en la ruta dada no existe cuando es justo delante de ti y puedes ver la cosa sangrienta).
3. No tiene ninguna operación de "clonación", tira de ramas una a la vez. Debe realizar un trabajo adicional si desea tener un repositorio para poder extraer nuevas ramas de manera eficiente.
4. Para algunos proyectos, es dolorosamente lento. Pruebe "bzr branch lp: mysql" alguna vez.
5. Carece de un fuerte soporte para ganchos; puede escribir complementos bzr que proporcionen enlaces, pero no existe una forma estándar de tener scripts de enlace arbitrarios del lado del servidor.

Recientemente cambié a git para el desarrollo de AllTray, y estoy considerando rápidamente migrar todos mis proyectos a git. Hay un poco más de tiempo inicial dedicado a conocer las cuerdas, pero parece valer 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 ramas que existen en el repositorio que clonó.
2. Agregar repositorios remotos adicionales es sencillo, por lo que puede realizar un seguimiento de muchos repositorios diferentes que tienen múltiples ramas si lo desea.
3. El libro Pro Git está disponible en línea y en múltiples formatos, incluso para dispositivos 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 bisección incorporada, y no puedo enfatizar lo suficiente la utilidad de esa característica.
6. GitHub es bastante agradable.
7. El gitosissistema también es bastante agradable. Ni siquiera estoy seguro de cómo se implementaría eso además de como un complemento en Bazaar, y no puedo imaginar que sea tan eficiente.

Larga historia corta: he usado bzr durante mucho tiempo, pero git rápidamente me está demostrando su genialidad.

Al usar git, tiende a permanecer siempre en el mismo directorio local cuando realiza el desarrollo, y simplemente lo hace git checkout branchnamepara cambiar entre ramas (utilizo ramas de funciones "ligeras" todo el tiempo, por lo que esta es una característica muy importante para mí).

Al observar la documentación y los tutoriales de Mercurial, parece que la forma preferida de tratar con diferentes ramas de desarrollo es crear nuevos repositorios mediante la 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 seguí algunos tutoriales)

No sé cuántas diatribas de este tipo he visto en las últimas semanas, pero todos parecen considerarlo como un hecho de que Mercurial y / o Bazar 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 constituya otro cambio de paradigma . Y señalar una tabla de características me dirá muy poco acerca de cuán flexible, extensible, seguro o sin esfuerzo es. Por ejemplo, por defecto git-diff usa colores y un buscapersonas. Claro que puedo obtener lo mismo con diff ... | colordiff | less -Ro algo así, pero debería ser obvio por qué uno es superior al otro.

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

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

Lo que quiero decir con control de versiones para programadores es que los programadores en general 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 ofrece a los programadores la flexibilidad de usarlo como quieran, a expensas de que tarde más en aprender cómo usar esa flexibilidad de manera segura. Permite que se establezcan restricciones para hacer cumplir las políticas, pero no sale así de la caja. Tenga en cuenta que dije facilidad de aprendizaje en lugar de facilidad de uso . Una vez que lo aprende, git es tan fácil de usar como cualquier otro VCS y, a menudo, más fácil debido a la mayor velocidad y características.

Algunos programadores aprenden lo suficiente como para hacer lo que quieren, 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 una ruta de migración algo más fácil.

No creo que sea justo decir que git solo es popular debido a la exageración o al respaldo de Linus. Eso probablemente explica que muchas personas lo prueben , pero se adhieren a él y lo promueven porque les funciona bien, puro y simple.

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

Tiene un nombre más ágil y conciso que se presta bien para juegos de palabras.

Recientemente estaba buscando un sistema de control de versiones para proyectos personales, así que probé un montón de ellos. Soy prácticamente analfabeta en la línea de comandos, y había escuchado que, aunque las GUI estaban disponibles, Git realmente estaba destinado a ser utilizado a través de la línea de comandos, lo que me hizo dudar un poco. Honestamente, sin embargo, fue ridículamente fácil de aprender, y realmente lo estoy disfrutando. La documentación es un factor enorme en la adopción de una nueva tecnología, y Git tiene toneladas de documentación ridículamente simple que está 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 se ha vuelto tan central para el movimiento de código abierto en este momento. Tener una ubicación centralizada (irónicamente) para intercambiar código y proyectos es un cambio de juego en sí mismo.

Solo mi 2 ¢: elegí git sobre las alternativas porque está escrito en C en lugar de un lenguaje de radio 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 permite su uso en pequeños entornos de desarrollo autohospedados que no incluyen intérpretes / tiempos de ejecución gigantescos, lo que significa que puedo extraer directamente de un repositorio de git y compilar en dichos sistemas en lugar de tener que buscar la última fuente en otro lugar y rsync.

Quizás le interese leer por qué el proyecto de escritorio GNOME eligió git sobre hg y bzr, cuando decidió mudarse de svn hace unos años. Hubo muchas discusiones religiosas acaloradas en el camino, por supuesto, pero esta página de GNOME Wiki resume muy bien los pros y los contras que se aplicaron a esa comunidad en particular.

Sin mencionar que Apple ahora se ha involucrado en llevarlo a la comunidad objetiva c, si ha creado una nueva aplicación en Xcode 4 recientemente, habrá notado que automáticamente le pregunta si desea hacer un repositorio de Git.

Concedido Xcode 4 solo ha existido durante unos 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.

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

¿Por qué estoy usando ahora?

Solo hay tres razones en este momento.

1. gitHub ofrece gists que son geniales
2. gitHub ofrece excelentes funciones sociales
3. Mientras realizaba presentaciones y talleres para desarrolladores, siempre publicaba mis muestras en hg y git. ¡En git tengo alrededor de 10 veces más visitantes que en hg!

Creo que el tercero es el más importante.

Thorsten

Pura suerte, supongo, hasta ahora casi imposible probar por qué algo funcionaba y otro no. Linus puede construir algo más espectacular y no tener éxito.