En más de una ocasión he sido consultado por organizaciones sobre la elección de sistemas de control de versión. Actualmente estoy trabajando con una organización que usa CVS y que está evaluando distintas herramientas para reemplazarlo.

Si bien basta con googlear un poco para encontrar miles de post sobre las diferencias, beneficios y problemas de los distintos sistemas de control de versiones, cambiar el sistema de control de versiones implica varias cuestiones no triviales.

Desde mi perspectiva estamos hablando de una herramienta que nos ayudará a resolver ciertas cuestiones de trabajo colaborativo y recalco esto: nos ayudará, la herramienta por sí sola no resolverá nada. Más aún, una herramienta mal utilizada puede traer más problemas que soluciones. Para que la herramienta nos permita resolver algún problema, debemos establecer ciertas reglas/convenciones para su uso (y luego respetarlas).

Dicho esto, deberíamos comenzar por identificar el/los problemas a resolver y luego analizar cómo es que cada alternativa de herramienta nos permitiría resolver esas cuestiones.

Desde mi óptica, hay 3 dimensiones de considerar en la evaluación.

Sistema de control de versiones: Git, Subversion, CVS, Mercurial, Darcs, son algunos sistemas de control de versiones. Para elegir uno posiblemente debamos comenzar por preguntarnos si queremos un sistema distribuido o centralizado y con ese punto de partida podremos ir acotando nuestras opciones. No voy a profundizar sobre este punto pues considero que es el que más desarrollado está y basta googlear un poco para encontrar pros y contras de cada uno.

Producto/Servicio: una vez elegido el sistema debemos elegir un producto o servicio que lo implemente. En este caso la discusión podría comenzar por: ¿queremos tener el sistema en nuestra infraestructura o preferimos contratarlo como servicio?. Una vez definido esto deberemos elegir un opción concreta. Ejemplo: supongamos que decidimos ir un sistema distribuido y concreto nos inclinamos por Git, entonces podríamos utilizar un servicio en la nube como el ofrecido por GitHub o Bitbucket o bien podríamos decidir adquirir un producto e instalarlo en nuestro entorno como podria ser GitLab o Stash.

Forma de uso: por más que hayamos elegido una producto/servicio concreto (supongamos GitLab), aún no basta para resolver nuestro problema, deberíamos definir ciertas cuestiones respecto de cómo usarlo. Esto implica responder preguntas tales como: ¿Cuál es el criterio para la creación de repositorios: creamos un único repo por equipo o creamos un repo por componente de nuestra solución? ¿usamos branches o forks? ¿cómo debería ser la estructura de cada repositorio?¿trabajamos todos sobre master o usamos feature branches?. Sin duda varias de estas cuestiones estarán influenciadas por la herramienta elegida pero más allá de eso, hay otra cuestiones que dependerán de problemática concreta de cada organización/proyecto.

En los últimos 2 años, he trabajado con al menos 5 organizaciones y en todos los casos la herramienta elegida ha sido Git. Si bien no siempre participé directamente en la elección de la herramienta, en varios casos estuve fuertemente involucrado en la definición de la forma de uso y la capacitación de los equipos.