Git: ¿Es un buen método para trabajar en equipo
Contenido
Git como sistema de control de versiones
Sistemas centralizados y distribuidos
A la hora de utilizar un Sistema de Control de Versiones debemos conocer los dos tipos que existen: centralizados y distribuidos.
En los sistemas de versiones centralizados cada desarrollador es un nodo de trabajo, y todos trabajan sobre un mismo repositorio central. En los sistemas de versiones distribuidos cada desarrollador puede ser tanto un nodo como un repositorio, es decir, cada desarrollador puede tanto contribuir a otros repositorios, como servir de repositorio público sobre el que otros desarrolladores pueden basar su trabajo y contribuir a él.
Subversion vs Git
Como ejemplo de sistema centralizado tenemos a Subversion. Subversion fue creado como alternativa a CVS, otro sistema de control de versiones centralizado, por lo que ofrece las mejores características de CVS y añade algunas mejoras. Aunque es un sistema muy popular tiene también algunos inconvenientes, por ejemplo, la ramificación carece de muchas características que sí tienen otros sistemas como Git o Mercurial. Por supuesto este sistema también tiene sus ventajas, aunque muchas organizaciones de código libre como Rails y PHP se han movido de Subversion a Git en los últimos años.
Por el otro lado tenemos Git, que es un sistema de control de versiones distribuido desarrollado por Linus Torvalds. También hay otros sistemas distribuidos bastante populares como Mercurial o Bazaar, pero vamos a hablar de Git por ser el más popular de los tres.
Las diferencias entre Subversion y Git las podemos ver mucho mejor viendo donde ocurren las operaciones (branch, commit, etc.). En el caso de Git, y del resto de sistemas distribuidos, las operaciones son locales, mientras que en Subversion ocurren en el servidor.
Esto quiere decir que en Git puedo hacer N commits antes de mandar los cambios al servidor, mientras que en Subversion cada commit se hace en el servidor. La principal consecuencia de este hecho es que en Git puedo hacer commits intermedios, sin necesidad de tener una versión “estable”, porque puedo hacer push al final. En Subversion, cuando hago un commit tengo que tener una versión consistente antes de hacer el commit para no romper nada que pueda necesitar alguien más, por lo que los commits en Subversion suelen ser bastante grandes.
Gracias a la emergencia de sitios como GitLab, BitBucket o GitHub, del que hablaremos más tarde, la revisión de código usando Git como sistema de control de versiones se ha vuelto mucho más fácil, y muchas organizaciones nuevas está optando por Git. Algunos sitos web muy grandes, como Twitter o Quora, usan Git. Y de hecho, todo el trabajo open-source que realiza Twitter se encuentra alojado en GitHub. Como dato, en Marzo de 2014 el proyecto Bootstrap de Twitter se convirtió en el repositorio más popular de GitHub con más de 24.000 forks y 67.000 estrellas.
Flujos de trabajo
Centralizado
Por supuesto aunque estemos en un sistema distribuido también podemos trabajar de forma centralizada. De este modo tendremos un repositorio central que guarda el código fuente, y los desarrolladores sincronizan su trabajo con él.
Esto significa que, si dos desarrolladores clonan desde el punto central, y ambos realizan cambios, tan sólo el primero de ellos en enviar sus cambios de vuelta lo podrá hacer limpiamente. El segundo desarrollador deberá fusionar previamente su trabajo con el del primero antes de enviarlo, para evitar sobrescribir los cambios del primero. En el caso de Git esto no es un problema, ya que en el caso de que el segundo desarrollador suba sus cambios sin haberlos fusionado primero, el servidor rechazará estos cambios y avisará al desarrollador de que esta intentando enviar cambios “no directos”, y de que no podrá hacerlo hasta que recupere y fusione los cambios que se han hecho antes.
Con un gestor de integración
Al permitir múltiples repositorios remotos, en Git es posible tener un flujo de trabajo donde cada desarrollador tenga acceso de escritura a su propio repositorio público y acceso de lectura a los repositorios de todos los demás. Habitualmente, este escenario suele incluir un repositorio canónico, representante "oficial" del proyecto.
La idea de este flujo de trabajo se basa principalmente en clonar un repositorio (público o privado si cumples los requisitos), hacer los cambios procedentes en el proyecto, y finalmente enviar una petición a la persona gestora del proyecto principal, para ver si el propietario de ese repositorio quiere incluir tus cambios en el proyecto “oficial”.
Con GitHub tu puedes hacer fork de su proyecto para incluirlo en tu cuenta, hacer los cambios apropiados y solicitar un pull request para ver si el propietario quiere meter los cambios que has hecho tu en el proyecto “oficial”
Dictador y tenientes
Es una variante del flujo de trabajo con múltiples repositorios. Se utiliza generalmente en proyectos muy grandes, con cientos de colaboradores. Un ejemplo muy conocido es el del kernel de Linux.
Unos gestores de integración se encargan de partes concretas del repositorio; y se denominan tenientes. Todos los tenientes rinden cuentas a un gestor de integración; conocido como el dictador benevolente. El repositorio del dictador benevolente es el repositorio de referencia, del que recuperan (pull) todos los colaboradores.
