5 buenas prácticas para trabajar con Git

¿Qué es Git?

Git es un sistema libre para control de versiones, el que se diferencia de otros (como SVN) por ser liviano y rápido.

Todo desarrollador de ésta era debiera haberse encontrado con Git por lo menos una vez en su camino, teniendo así, nociones básicas de su uso. Sin embargo, en el caso de nunca haber usado Git antes, te recomiendo que visites este link, en 15 minutos ya debieses saber lo básico.

El objetivo de este post no es dejarte hecho todo un maestro de las artes de Git, si no simplemente darte unos pequeños tips (5) que te permitirán tener un desarrollo ordenado y limpio.

Ya teniendo un poco de Git en la cabeza, empezamos:

1. Haz muchos commits

Cada vez que hagas un cambio, por pequeño que sea, si altera la funcionalidad de tu código haz un commit. No esperes a tener varias modificaciones no relacionadas entre si para hacer un commit.

En mis principios, mis commits generalmente eran del trabajo que había hecho durante el día, lo que incluía una gran cantidad de cambios. Con el tiempo y a la fuerza aprendí que era un error, muchas veces me encontraba nadando en los cambios para detectar qué parte del código había generado un bug.

Este consejo te ayudará para que si en el futuro decides deshacer algún cambio o si se te olvidó como solucionaste algo, puedes encontrar justo lo que necesitas y no ahogarte en el mar de cambios.

2. Comenta bien los commits

Además de no saber en dónde estaba mi cambio, me encontraba mirando dentro de cada commit buscando lo que quería. Todo hubiese sido mejor si alguien, al ver nombres como ""Cambio 18 noviembre"" o el clásico ""asdasd"" me hubiera dicho ¡Así no se hace!. Al igual que nombrar tus variables con un nombre descriptivo como 'userName' en vez de 'var1', los commits descriptivos hacen la revisión de tu código un trabajo mucho más fácil.

En mi equipo de trabajo tenemos un semi protocolo para nuestros commits, al inicio del mensaje se dice de qué tipo es el cambio (e.g ADDED, UPDATED, FIXED, DELETED), luego se listan los archivos que se ven afectados y por último una breve descripción del cambio.

Algunos ejemplos:
  • Si agregaste un nuevo stylesheet al proyecto
    • ADDED styles/about.scss: Hoja de estilos creada para la página about
  • Al cliente no le gustó el color de la tipografía:
    • UPDATED styles/about.scss: Cambio color fuente a rojo
  • Se dan cuenta de que no quieren explicar quienes son:
    • REMOVED styles/about.scss pages/about.html: La página about fue eliminada

3. No hagas commits de cosas a medias

No hagas commits sólo por obedecer el primer consejo. Haz un commit cuando el trabajo esté listo, esto no significa que puedas commitear solo cuando la página, función, script, etc esté lista, si no que es mejor dividir el trabajo en partes lógicas e ir completando y realizando commits de cada una cuando hayas terminado.

No hagas commits porque terminó la hora laboral y quieres irte. Ante esta inminente tentación, prefiere usar el stash, que te guarda todos los cambios sin commitear para luego poder hacerlo cuando sea debido.

Además, al terminar lo que estás haciendo ¡pruébalo!, de esta manera te aseguras de que esté completamente terminado y no afecte otras partes de tu código.

4. Irse por las ramas es bueno

Todo proyecto que tenga como fin ser usado e irse mejorando con el tiempo, necesitará como mínimo dos branches, una para desarrollo y otra para producción.

En producción claramente solo se deben tener cosas terminadas y testeadas, para así evitar embarasosas caídas en público.

En desarrollo se van haciendo las mejoras y agregando funcionalidades para la próxima release. Si estás trabajando en equipo o desarrollas multiples funcionalidades a la vez, cada una de estas debiese tener una branch por separado, de forma que los cambios creados por algunos no sean estropeados por otro que está trabajando en algo distinto.

5. Una hormiga no hace nada sin el hormiguero (estandarización)

¿De nada sirve pintar el mejor cuadro del mundo si tu compañero se pone a usarlo como diana para una pistola de pintura? Cuentale a tu grupo de trabajo sobre como usas Git, lleguen a un acuerdo y estandaricen el trabajo, para que así sea realmente útil para todos trabajar con Git.

¿Y ahora qué?

Como desarrollador, sería completamente erroneo decir que ésta es la forma de usar Git.

Son tan sólo simples consejos que he seguido, consiguiendo un trabajo ordenado y facilitandome muchas veces ciertas tareas.

Como último consejo, te recomiendo siempre seguir leyendo sobre el tema. Hay gente que sabe mucho sobre Git, de los cuales podrías aprender muchos tips y tal vez mejores que los descritos aquí.