Reglas básicas y convenciones de nomenclatura para la gestión de ramas con varias personas en GitHub

En esta serie de artículos, has aprendido desde los usos básicos de GitHub hasta cómo contribuir al desarrollo colaborativo utilizando `Fork` y `Pull Request`. ¡Ya no tienes por qué temer al desarrollo individual ni a la contribución a proyectos de código abierto!

En esta última entrega de la serie, nos centraremos en la "gestión de ramas" para facilitar el desarrollo en equipo. Cuando varias personas trabajan en el mismo repositorio, si no hay reglas, el caos puede sobrevenir en un instante. ¡Aprendamos las reglas básicas para la gestión de ramas y las convenciones de nomenclatura fáciles de entender para que todos miren en la misma dirección y desarrollen de manera eficiente, y aspiremos a ser maestros del desarrollo en equipo!

¿Por qué son necesarias las reglas de gestión de ramas?

¿Qué pasaría si no hubiera reglas para la creación de ramas en un equipo?

La persona A crearía `feature-A`, la persona B `fix-B`, y la persona C `sato-branch`. Cada uno empezaría a crear ramas con nombres arbitrarios. Así, nadie sabría para qué sirve cada rama. Como resultado, proliferarían las ramas innecesarias, los errores de fusión (merge) serían frecuentes y el desarrollo se sumiría en el caos.

Para prevenir este caos y avanzar en el desarrollo sin problemas, es indispensable contar con unas sencillas "reglas de gestión de ramas (estrategia de ramificación)" compartidas por el equipo. Existen estrategias de ramificación famosas como "Git-flow", pero para empezar, es más que suficiente con aprender los fundamentos de un "flujo de trabajo de ramas de funcionalidad" (feature branch workflow) más simple.

Tipos de ramas básicas y sus roles

En el desarrollo en equipo simple, se suelen utilizar principalmente dos tipos de ramas. Entendamos bien el papel de cada una.

• Rama `main` (antigua rama `master`)

  Esta es la rama sagrada para guardar el "código del entorno de producción que siempre funciona correctamente". Es absolutamente necesario evitar editar esta rama directamente o que se mezcle código inestable en ella.

  【Regla】: Nadie debe hacer commit o push directamente a la rama `main`. Todos los cambios deben fusionarse a través de Pull Requests desde ramas de funcionalidad, que se explican a continuación.

• Rama de funcionalidad (Feature Branch)

  Esta es una rama de trabajo que se crea para realizar una tarea específica, como el desarrollo de una nueva función, la corrección de un error o una pequeña mejora. A veces también se le llama "rama de tópico". Se ramifica desde la rama `main` y, una vez completado el trabajo, se fusiona de nuevo en la rama `main`. Es una rama de vida corta que se elimina una vez que el trabajo ha terminado.

  【Regla】: Por muy pequeña que sea la corrección, empieza siempre creando una nueva rama de funcionalidad.

Convenciones de nomenclatura fáciles de entender para las ramas

Para que cualquiera pueda entender las ramas de funcionalidad, es importante tener una convención de nomenclatura coherente. Generalmente, se utiliza el formato " `prefijo/descripcion-del-trabajo` ".

Tipos de prefijos y ejemplos concretos:

• feature/: Cuando se añade una nueva funcionalidad.
  • Ejemplo: feature/add-login-page (Añadir página de inicio de sesión)
• fix/: Cuando se corrige un error.
  • Ejemplo: fix/correct-header-layout-bug (Corregir error de diseño en la cabecera)
• refactor/: Cuando se mejora la calidad del código sin cambiar la funcionalidad (refactorización).
  • Ejemplo: refactor/optimize-database-query (Optimizar consulta a la base de datos)
• docs/: Cuando se modifica la documentación (como README.md).
  • Ejemplo: docs/update-installation-guide (Actualizar la guía de instalación)

Si compartes estas reglas con tu equipo, cualquiera podrá saber para qué sirve una rama con solo ver su nombre.

¡En la práctica! El flujo básico del desarrollo en equipo

Ahora, veamos el flujo básico del desarrollo en equipo basado en estas reglas, junto con los comandos.

Paso 1: Obtén la última versión de la rama `main`

Antes de empezar a trabajar, asegúrate siempre de actualizar tu rama `main` local al estado más reciente del repositorio remoto. Primero, cambia a la rama `main`.

git checkout main

A continuación, trae la información más reciente del remoto a tu local.

git pull origin main

Paso 2: Crea una rama de funcionalidad para tu trabajo

Desde la rama `main` actualizada, crea una rama de trabajo para ti. Esta vez, vamos a crear una rama asumiendo que vamos a "añadir un formulario de contacto".

git checkout -b feature/add-contact-form

Paso 3: Realiza las modificaciones/desarrollo y haz commit

En la nueva rama que has creado, modifica y añade código a tu antojo. Cuando hayas completado una parte del trabajo con sentido, crea un commit.

git add .

git commit -m "Añadir estructura básica del formulario de contacto"

Paso 4: Haz push al repositorio remoto

Haz push de la rama de funcionalidad que has creado al repositorio remoto. Esta es la primera vez que tu trabajo será visible para los miembros de tu equipo.

git push origin feature/add-contact-form

Paso 5: Crea una Pull Request y recibe feedback

Una vez que hayas hecho push, crea una Pull Request en GitHub dirigida a la rama `main`. Pide a los miembros de tu equipo que revisen tu código y te den su feedback. (Consulta el artículo anterior para saber cómo crear una Pull Request).

Paso 6: Después de la fusión, elimina la rama innecesaria

Una vez que la Pull Request se haya fusionado con éxito, la rama de funcionalidad que usaste para ese trabajo ya no es necesaria. Para mantener el repositorio limpio, elimínala.

Primero, elimina la rama remota. Esto normalmente se hace simplemente pulsando el botón "Delete branch" que aparece en la página de la Pull Request de GitHub después de la fusión.

[Imagen: El botón "Delete branch" que se muestra después de una fusión.]

A continuación, elimina también la rama que queda en tu local. Primero, volvamos a la rama `main`.

git checkout main

Y luego, elimina la rama local que ya no necesitas.

git branch -d feature/add-contact-form

Con esto, se completa un ciclo. Cuando empieces un nuevo trabajo, repite desde el paso 1.

Conclusión: Unas reglas simples salvan al equipo

El secreto para tener éxito en el desarrollo con varias personas no es aprender reglas complejas, sino que todos sigan constantemente unas reglas simples. Con solo aplicar rigurosamente en el equipo las reglas básicas que hemos presentado, la eficiencia del desarrollo aumentará drásticamente y podréis evitar problemas innecesarios.

• Proteger siempre la rama `main`.
• Realizar todo el trabajo en ramas de funcionalidad.
• Ser riguroso con las convenciones de nomenclatura claras.
• Fusionar con `main` siempre a través de una Pull Request.
• Eliminar con frecuencia las ramas ya fusionadas.

Con esta serie de introducción a GitHub, has aprendido desde la creación de una cuenta hasta el flujo básico de desarrollo colaborativo. Este es un gran paso adelante como creador web. Utilizando los conocimientos adquiridos aquí como base, te animamos a que utilices activamente Git y GitHub en tus proyectos reales. ¡Esperamos que tu vida como desarrollador sea más cómoda y creativa!