Guías de Git. Porque un commit vale más que mil palabras

No encontré mejor forma de darle título a este post. En todo caso no importa. Lo que sí importa son los tres enlaces que les voy a compartir. Son enlaces a diferentes guías para trabajar con Git.

Cómo toda guía, no es que sea palabra escrita en piedra pero al menos sí deberías, como desarrollador, apegarte a alguna. Al igual que con tu código fuente, la organización de tus archivos, las nomenclaturas y más, el orden y el sentido coherente ayuda a crear proyectos más organizados(obviamente) y a la larga los hace mantenibles.

Hace algunos artículos atrás, les intentaba mostrar la ventaja de hacer commits frecuentemente en Git. Esto por motivo de que un commit fácilmente funciona como una especie de backup para volver a una versión anterior del archivo, fragmento de código o hasta una línea y porque también permite llevar un registro de todo lo que se va haciendo.

Sin embargo, no es escribir commits a la ligera. Es mucho mejor cuando se tiene un sentido lógico en lo que se escribe en el commit. Un mensaje acorde a lo trabajado, más adelante, te ayudará cuando necesites encontrar un parte que funcionaba y ya no, algo que pudiste haber hecho mal o cualquier cosa que quieras recordar.

Es así cómo a lo largo de los meses me he topado con, hasta ahora, tres guías muy buenas(a mí parecer) sobre cómo trabajar con Git. Esto es, el flujo de trabajo(usando ramas) y los mensajes para los commits. Veamos.

flujo de ramas en git

La guía de Katana

Katana es una empresa escocesa dedicada a hacer software. A manera de gist, comparten su guía de trabajo para utilizar Git en sus projectos de software.

Si bien en su guía no entran en detalle sobre los commits, sí lo hacen sobre cómo trabajar las ramas para ciertos requerimientos. Le llaman topic branches. En español sería algo como “ramas de temas”. Es decir, cada rama representa un requerimiento técnico a trabajar, un error a solucionar, un asunto de mercadeo o configuraciones. Ejemplo, si en el proyecto para crear una calculadora hay 4 requerimientos:

  • Sumar
  • Restar
  • Multiplicar
  • Dividir

Una rama de trabajo, según esta guía, sería algo como:

git checkout -b feature/sumar

Usando el modificador -b le decimos a git que cree la rama y nos ubique inmediatamente en ella.

Para una rama de error podría ser algo como:

git checkout -b bug/suma_hace_resta

Muy similar a los commits, las ramas ayudan a entender que ocurre en el proyecto mientras esta exista. Según el tipo de proyecto o guía, puede que las ramas sean temporales o permanentes. La guía de Katana la veo más en proyectos donde las ramas perduran por tiempo o donde los requerimientos toman semanas en completarse.

Mira la guía completa en Github.

La guía de Thoughtbot

Estos señores son muy reconocidos en el mundo del desarrollo de software. Son una empresa grande dedicada a la consultoría principalmente pero también tienen a las personas facultadas para llevar a cabo el código fuente que necesita un proyecto. Adicional, tienen un blog muy bueno sobre conceptos, buenas prácticas y más y tienen muchos libros publicados.

Lo anterior es solo para darle validez a su guía para Git. Esta sí hace un esfuerzo por abarcar más temas tanto de flujo(trabajo con ramas) hasta de commits.

Para las ramas manejan una sintaxis similar a Katana pero siendo menos estrictos con los nombres. Siguiendo con el proyecto de la calculadora, en Thoughtbot harían algo así:

git checkout -b sumar

Te dicen que escribas un buen mensaje de commit al finalizar de trabajar o cuando hayas completado el requerimiento.

No es válido un commit así:

Sumar números

Más bien, deberías apuntar a escribir mensajes más completos:

Sumar números.

- Validar que se ingrese más de un número
- Indicar los miles con punto y no con coma

Más o menos esa es la idea. El commit debe ser muy descriptivo porque hoy te acuerdas de lo que hiciste pero, ¿lo harás en 6 meses?

A diferencia de Katana, en Thoughtbot cuando subes una rama al repositorio, luego de que se complete el pull request(cuando tu rama de trabajo se une con master), puedes proceder a borrar tanto tu rama local como la rama en el servidor.

Borrar la rama local:
git branch -d sumar

Borrarla del servidor:
git push origin --delete sumar

Puedes ver la guía completa en Github.

La guía de Ghost

Ghost es un CMS desarrollado usando NodeJS. La gente detrás de este enorme proyecto liberó en Github su guía de cómo trabajar el flujo y los commits. A diferencia de las guías anteriores esta es un poco más completa. Dado que Ghost es un proyecto de código fuente abierto mantener una serie de estándares es algo preciso para la buena organización y trabajo entre todos los colaboradores.

En esta guía se tratan varios aspectos y se detallan en un documento muy bien elaborado. En la guía para Git de Ghost encontramos:

  • Escribir buenos mensajes de commits: en este hay más tips sobre cómo hacerlo que pueden fácilmente llevarse a otros proyectos
  • Una buena explicación a los Pull Requests y cómo usar el comando `git rebase`
  • Trabajar en resolver problemas o issues
  • Hitos o milestones.

Debes mirarla y leerla con atención para aprender cómo un proyecto open source usa Git. Seguro hay algo que aprender.

Muy seguramente habrá más empresas o proyectos con un flujo de trabajo mejor o más óptimo según las circunstancias, sin embargo, lo más importante es tener uno, seguirlo y mejorarlo con el tiempo.

Autor: cesc1989

Ingeniero de Sistemas que le gusta escribir y compartir sobre recursos que considera útiles, además que le gusta leer manga y ver anime.

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s