Buenas prácticas para el uso de Git y GitHub

GitHub es una de las mejores herramientas que existen para el uso con Git: facilita el trabajo y la interfaz es amigable con el usuario, pero a veces no se sabe sacar el máximo provecho de todas sus bondades. Hoy les daré una serie de consejos que pueden ayudar a mejorar su vida como programador.

Consejos básicos para usar Git

• Registro de cambios: un commit puede tener cientos de cambios o solo un cambio. Lo ideal es crear cambios granulares para que otros desarrolladores puedan entender los cambios que se han realizado, y si algo sale mal pueda ser revertido con facilidad.
  
  
• Hacer commits con más frecuencias: realizar esto conlleva a una mayor información para todo el grupo de trabajo sobre los cambios que se han realizado, de esta manera se evitan conflictos a la hora de mezclar los cambios.
  
  
• Revisar el código antes de hacer un commit: con esto evitamos rehacer un commit o hacer commits adicionales innecesarios.
  
  
• Evitar commits con códigos a la mitad: enviar a un repositorio un commit con métodos o funciones no terminadas es un error que hay que evitarse; hay que compartir código completo.
  
  
• Escribir buenos mensajes en los commits: un mensaje ideal sería de un máximo de 72 caracteres que responda las siguientes preguntas: ¿Cuál fue el motivo para el cambio? ¿En qué difiere del código anterior?
  
  
• Usar ramas: aplicar el uso de ramas se debe hacer desde el primer día en un proyecto, esto evita mezclar código de distintas líneas de desarrollo. Es importante usar ramas para: nuevas características, ideas, corrección de errores.
  
  
• Utilizar un flujo de trabajo: coordinar con el grupo de trabajo sobre cual debe ser el flujo de trabajo depende de muchos factores, sobre todo el tipo de proyecto, lo importante es que se tenga claro cual será y aplicarlo.
  
  
• Separar archivos en otros repositorios: con esta acción se incentiva a la reutilización de código.
  

Flujos de trabajo en Git

Existen distintos flujos de trabajo que pueden ver con mayor detalle en el siguiente enlace: Atlassian Workflow Overview.

Uno de los flujos de trabajo más usado es “Feature Branch Workflow”, donde cada nueva función se agrega a través de una rama partiendo de la rama master, y aplicando pull request para la mezcla del código original con las nuevas funciones. Este flujo de trabajo es uno de los más sencillos aparte del modelo centralizado; algo importante de mencionar es que tomando Feature Branch Workflow para los repositorios actuales, podríamos luego subir de nivel hacia Gitflow Workflow, ya teniendo un control total de fechas de release y muchas otras cosas.

Funcionamiento de Feature Branch Workflow

El funcionamiento de este flujo de trabajo es muy sencillo, y se partirá desde master con una rama específica para los cambios que realicen, con un nombre representativo. Ej: error-con-vistas.
Al tener en el equipo local, se procede a hacer los cambios recordando los consejos básicos. Una vez terminados los cambios, se procede a realizar acciones especiales para estar seguro que no hayan conflictos con la rama master.

1. Ir a la rama master: git checkout master.
   
2. Traer los últimos cambios: git pull origin master.
   
3. Crear una nueva rama: git checkout -b master-pre-merge.*
   
4. Estando en la nueva rama basada en master se realiza la prueba de mezcla: git merge error-con-vistas.**
   
5. Si algo sale mal, se debe revisar el código que tiene conflicto, y volver al punto 1.
   
6. Si todo sale bien, se elimina la rama master-pre-merge.
   
7. Al llegar a este punto se realiza el pull request, que perfectamente se puede hacer desde GitHub.
   

* Puede tener otro nombre esta rama de prueba, y no debe ser empujada hacia el repositorio remoto.
** El nombre de la rama con la que se está trabajando actualmente.

Pull Requests en Github

Este es el penúltimo paso para agregar un cambio a la rama master donde se debería encontrar todo el código que funciona actualmente en producción. En los pull requests se debe discutir acerca del código y las funciones propuestas, de esta manera se pule el código antes de ser mezclado y evitamos “ensuciar” el repositorio.

La revisión de cada pull request la puede hacer cualquier persona con accesos a los repositorios, por lo tanto se podría requerir al menos una persona que lo revise y acepte. Una vez aceptado el código, se mezcla y elimina la rama con la que se trabajó, así evitamos tener cientos de ramas creadas que generan más peso al repositorio, ya en el pull request está la información que se necesita saber y queda un historial.

Podríamos poner a consideración lo siguiente: tener una rama de pre-producción que una vez comprobado que el último merge con las ramas de nuevas funcionalidades esté listo, ahí sí se lleve al merge con la master, para evitar cualquier sorpresa.

¿Sabes SQL? ¿No-SQL? Aprende MySQL, PostgreSQL, MongoDB, Redis y más con el Curso Profesional de Bases de Datos que empieza el martes, en vivo.