Git, ¿merece la pena?

Un sistema de control de versiones es una de las principales herramientas para cualquier programador, independientemente de si se esté trabajando en solitario o con un equipo de cientos de personas.

Desde hace un par de semanas estoy usando Git, un sistema de control de versiones distribuido desarrollado por Linus Tolvards (usado actualmente en el desarrollo del kernel). Git, está teniendo últimamente mucho hype. Pero las modas son muy peligrosas y siendo una herramienta tan fundamental, hay que evaluar a conciencia si realmente merece la pena usarla.

Comentando mi experiencia personal, tengo que decir que nunca me han gustado los SCMs. Comencé a usar subversion después de aprender a base de palos algunas de las causas de no usarlo. Aunque hasta hace poco no lo usaba plenamente, o todo lo bien que debería como para que empezase a ser una herramienta y no una carga. Pero a pesar de ello, todavía tenía auténtico pánico cada vez que se me pasaba por la mente las palabras branch o merge. Auténtico pánico.

Por suerte todo aquello es cosa del pasado (de hace 2 semanas :P). Lo que me animó a probar Git fue este estupendo post, merging by example, donde se muestra un ejemplo de uso en el que se van realizando diversos branches y merges de una forma lógica en un escenario típico del MundoReal™. Intenta hacer eso mismo con subversion (o si eres del pasado, con tu cvs) y me comentas (no pasarás del tercer merge sin conflictos).

Basta de contar mi vida y decir pamplinas, ¿qué ventajas aporta Git respecto a subversion? (digo subversion porque es el comúnmente usado, lo mismo se podría decir respecto a cvs pero con todavía más puntos).

  • Está de moda, y si lo usas molarás más, ¿no?. No hay mejor conversación para atraer a humanos del género opuesto que comenzar con un típico “¿sabes que uso git con una mano?”
  • Es distribuido. Esto tiene dos implicaciones muy importantes:
    • Independencia. Tú eres un repositorio, no necesitas ninguna información de ningún otro lado para realizar las operaciones. Es decir, no necesitas para nada red.
    • Mejor integración y comunicación en grupos de desarrollo grandes, pues cada desarrollador puede compartir cambios con el resto sin depender de un servidor central.
  • Rapidez, derivada principalmente por el anterior punto (y porque los que lo han implementado no deben de ser malos programadores, a decir verdad, según Linus la eficiencia fue uno de sus requisitos principales). Si para realizar una operación vas a necesitar acceder a la red (svn), quieras o no quieras vas a ser siempre mucho más ineficiente que alguien que no lo necesita (git)
  • Manejo más simple, intuitivo y eficiente de branches.
    • Con git puedes mergear varias ramas a la vez en una tercera (llamado merge octopus).
    • Mergear eficientemente ramas cuyo punto en común es un antiguo padre.
    • Y lo más importante (para mi :P), el scm conoce qué es un branch. Se acabo eso de tener diferentes directorios, uno por branch.
  • Git sigue y almacena contenido, no ficheros como lo hace svn. Esto tiene importantes repercusiones, una es (que podría considerarse negativa, para mi al menos lo es) que no soporta almacenar directorio vacíos (¡pues no tienen contenido! no hay nada que salvar) y otra es una detección transparente de movimiento de ficheros (renombrado, copias, movimientos, etc…).
  • Nuevo concepto, el index. El índice es un punto intermedio entre nuestros ficheros reales en el directorio de trabajo y el repositorio. Permite ser usado como un punto intermedio en el que almacenar (y preparar) nuestro cambios. En él podemos guardar nuestras modificaciones de forma temporal y recuperarlas posteriormente (por ejemplo después de cambiar de rama y arreglar lo que sea). O también podemos crear un commit personalizado creando un parche llegando a la granularidad de líneas de ficheros.

En resumen, es un cambio realmente significativo respecto al modelo tradicional (aunque podrías usar git con el mismo “workflow” que sigues en svn). De primeras es muy fácil de usar (algo que siendo un patan con estas herramientas, como lo es un servidor, se agradece), pero a su vez te permite profundizar y conseguir nuevos modelos de trabajo más productivos gracias a sus enormes posibilidades (el index es realmente útil). Es decir, tiene una curva de aprendizaje razonable pero que llega muchísimo más alto que la de svn (en cuanto a posibilidades), algún día llegaré a dominarlo pero mientras tanto me hace la vida más fácil.

Además puede ser usado teniendo repositorios de otro tipo como maestros (svn, por ejemplo gracias a git-svn), por lo que puedes seguir usando svn y localmente usar git sin “problemas” (tú trabajas con git, y git-svn se ocupa de manejar el subversion remoto, así estoy trabajando actualmente).

Por último mencionar algunas alternativas muy similares a git (es decir, que son distribuidos), los cuales desconozco completamente, pero que estoy casi seguro que son una mejor apuesta respecto al modelo svn/cvs. Los dos primeros escritos en python y el último en Haskell (¡con un par!):

Todo se podría resumir en una moraleja: Git, el sistema de control de versiones que no produce un incremento de deseo de participar en un suicidio colectivo.

7 Thoughts on “Git, ¿merece la pena?

  1. Gracias! Esperaba con ganas este post.

    La verdad es que sólo he trabajado con svn y no nos ha ido mal. Pero tendré muy en cuenta a git. 😀

  2. Aunque parezca sorprendente, la rapidez de git no se da por la red (aunque es un punto importante).

    En unas pruebas que hice con el repositorio de ebox, un simple checkout le costaba a svn 6 veces mas que a git (haciendolo todo en local)

  3. Yo, como tú, cuando tengo que hacer merges… TIEMBLO. Hoy subí varios cambios y no veas algunos archivitos para quitar los conflictos..

  4. Ahora mismo tengo un branch totalmente broken porque subversion no me detectó los conflictos en ficheros que habían sido renombrados en ambas ramas (tanto en el branch como en el trunk) por lo que tengo contenidos perdidos. Algún día me pondré a ello.

    Ésto con Git nunca pasaría, pues, como he comentado, sigue contenidos, y no ficheros. Algo que beneficia y facilita los merges.

  5. No sé si al final nos animaremos a probar algo de esto… Bellz nos envió unos links de Bazaar……….. lo mismo migramos ahora que la peña en el curro empieza a usar SVN 😉

  6. habra que probarlo porque justo ahora empiezo a usar SVN para un proyecto y en el trabajo aun usan CVS :S

    Saludos

  7. Yo ando en probarlo auno no me queda muy muy claro como usarlo en Eclipse yo desarrollo con php y uso Eclipse para esto lo instale y todo pero como en SVN me aparecen todos con un simbolito de que esta sincronizado con el servidor y con git solo el principal y los demas no pues me hice pelotas no me dedico al desarrollo profecionalmente hago algunas que otras cosillas hehehe le are otro intento aver k pex sale pues gracias por el post me anima a volver a probarle ya que me aclaro algunas cosillas ^_^

Post Navigation