Por qué git

Lo confieso: como desarrollador solitario, nunca había sido amigo del control de versiones. Como serlo, si requería tener corriendo un servicio, con las configuraciones y reconfiguraciones que ello conlleva (por mi manía de siempre probar la última distro)? Jamás me sentí a gusto con CVS, sin poder saber a ciencia cierta por qué.

Hasta que conocí git. Primero que nada, git es una aplicación. No requiere tener un servidor corriendo. Tu repositorio esta en el mismo directorio que tu proyecto, por lo que el respaldo es mas sencillo. Solo tipeas los comandos y ya!

En segundo lugar, es distribuido. Trabajo al menos en un par de computadores, sin contar una que otra laptop que uso de vez en vez contra mi voluntad. Puedo tener en cada equipo mi proyecto con toda su historia, trabajar independientemente y luego sincronizar con los demás. Cada PC es un equipo de desarrollo tan igual como los demás.

En tercer lugar, puedo elegir la estructura de mis repositorios, como se organizan jerarquicamente. En mi ciclo de trabajo personal elegí no tener un repositorio central, pero en el trabajo, donde más de una persona puede hacer cambios en un proyecto, usamos un maestro.

Pero la característica matadora de git son definitivamente sus branches. Hacer una rama de un proyecto es tan natural, tan barata, que forma parte integral de la forma de desarrollo en git. No puedo resaltar suficientemente este hecho: git me ha hecho un mejor usuario de los sistemas de versiones.

Como es esto? Dado que en mis experiencias previas, ramificar el proyecto era doloroso, tenía una única rama, donde aplicaba todos los cambios. Si trabajaba en tres aspectos distintos de una aplicación, todos los cambios iban al directorio de trabajo. De esta manera, los commits contenían cambios no relacionados. Hacer un commit era básicamente, hacer un respaldo del proyecto.

Fue usando las ramas de git que obtuve la iluminación: un aspecto, una rama. Aspecto culminado, commit. Apareció un bug que debo atender? Pues creo una nueva rama, corrijo el bug, pruebo y hago el commit y merge o rebase. Regreso a la rama inicial y sigo trabajando con el aspecto original.

Cada commit debe ser un milestone, un hito significativo en el desarrollo del programa "Agregue la caracteristica X", "Corregí el bug Y", "Cambié el algoritmo Z". Y no como antes "Toqué los archivos A, B, C, D y E porque estoy trabajando en X, Y y Z", repetido día tras día..