Concepto de branching: Separar líneas de desarrollo

El branching o creación de ramas sirve para que los equipos de un proyecto puedan trabajar a la vez sin causar conflictos. Una rama es una línea paralela de desarrollo que permite separar el trabajo en diferentes vías, sin interferir con el código principal. Así, los desarrolladores pueden trabajar en funcionalidades independientes o correcciones de errores sin que sus cambios se mezclen.

Las ramas en Git son referencias ligeras a un punto concreto en el historial de commits. Al crear una nueva rama, se genera un puntero que apunta a un commit específico, permitiendo continuar el desarrollo desde ese punto sin afectar a otras ramas. Con las ramas es posible desarrollar nuevas característicassin riesgo de alterar el código estable.

Cada funcionalidad o tarea puede desarrollarse en su propia rama, y así hacer más fácil la revisión y fusión de cambios cuando estén listos, esto permite aislar problemas que puedan surgir.

El uso de ramas también simplifica la gestión de versiones. Por ejemplo, se puede mantener una rama estable para las versiones de producción y desarrollar nuevas funcionalidades en ramas separadas hasta que estén listas para ser integradas. De esta manera, se evita introducir cambios no deseados en el entorno de producción.

Creación y cambio de ramas: git branch, git checkout, git switch

Para gestionar diferentes líneas de desarrollo en Git se necesita saber crear y cambiar entre ramas. El comando git branch permite crear nuevas ramas, mientras que git switch y git checkout se utilizan para cambiar entre ellas.

Para crear una nueva rama, se usa git branch seguido del nombre deseado:

git branch nueva-funcionalidad

Este comando crea una rama llamada nueva-funcionalidad que apunta al commit actual, pero no cambia a ella automáticamente. Para listar todas las ramas disponibles y ver en cuál se está trabajando, se ejecuta:

git branch

El asterisco (*) indica la rama activa en el momento.

Para cambiar a una rama existente, Git tiene dos comandos: git switch y git checkout. Pero a partir de las versiones más recientes se recomienda utilizar git switch:

git switch nueva-funcionalidad

Este comando cambia el directorio de trabajo a la rama nueva-funcionalidad, para poder continuar el trabajo en esa línea de desarrollo.

Aunque git checkout también sirve para cambiar de rama, su uso es más amplio y puede ser un poco confuso. Por ejemplo:

git checkout nueva-funcionalidad

Además de cambiar de rama, git checkout se utiliza para restaurar archivos, así que esto igual lleva a errores si no se tiene cuidado. Por esta razón, se recomienda usar git switch para cambiar de rama y git restore para restaurar archivos.

Para crear y cambiar a una nueva rama en un solo paso, git switch ofrece la opción -c:

git switch -c correccion-error

Este comando crea una nueva rama llamada correccion-error y cambia a ella al momento.

En resumen, los comandos más comunes para trabajar con ramas son:

• git branch nombre-rama: crea una nueva rama sin cambiar a ella.
• git switch nombre-rama: cambia a una rama existente.
• git switch -c nombre-rama: crea una nueva rama y cambia a ella.
• git checkout nombre-rama: cambia a una rama existente (uso tradicional).

Comparación y fusión de ramas: Flujos de trabajo básicos

La comparación de ramas sirve para identificar diferencias entre distintos puntos de desarrollo. Para comparar el contenido de dos ramas, se utiliza el comando git diff seguido de los nombres de las ramas:

git diff rama-origen rama-destino

Este comando muestra las modificaciones que existen en rama-destino con respecto a rama-origen. Se usa para revisar cambios antes de fusionarlos y asegurarse de que todo está en orden.

La fusión de ramas o merge es el proceso por el cual se integran los cambios de una rama en otra, y se usa el comando git merge. Para fusionar una rama llamada feature en la rama actual, se ejecuta:

git merge feature

Git siempre va a intentar combinar automáticamente los cambios. Si no hay conflictos, la fusión se completará y la rama actual incorporará los nuevos cambios. En caso de conflictos, Git mostrará los archivos afectados y habrá que resolverlos manualmente.

Un flujo de trabajo básico con ramas podría seguir estos pasos:

1. Crear una nueva rama para desarrollar una funcionalidad específica:

git switch -c nueva-funcionalidad

2. Desarrollar y confirmar cambios en la rama nueva-funcionalidad con commits pequeños y descriptivos.

3. Cambiar a la rama principal (por ejemplo, main o master) cuando la funcionalidad esté lista:

git switch main

4. Fusionar la rama de funcionalidad en la rama principal:

git merge nueva-funcionalidad

5. Eliminar la rama de funcionalidad si ya no es necesaria:

git branch -d nueva-funcionalidad

Cuando se trabaja de esta forma se puede mantener la rama principal en un estado estable, mientras las nuevas características se desarrollan y prueban en ramas separadas.

Para facilitar la fusión y evitar conflictos, se recomienda actualizar de vez en cuando la rama de funcionalidad con los últimos cambios de la rama principal, fusionando main en nueva-funcionalidad mientras se trabaja:

git switch nueva-funcionalidad
git merge main

Si se hace esto, se integran los cambios más recientes y se resuelven posibles conflictos de forma anticipada.

Otra práctica que se usa mucho es utilizar git merge --no-ff para mantener un historial más claro:

git merge --no-ff nueva-funcionalidad

La opción --no-ff fuerza la creación de un commit de fusión, incluso si un fast-forward es posible. Esto sirve para preservar la historia del desarrollo y hace más fácil el seguimiento de qué cambios provienen de cada rama.

Por último, suele ser útil visualizar el historial de ramas y fusiones mediante el comando:

git log --oneline --graph --all

Este comando muestra un gráfico simplificado del historial de commits para ver cómo se han integrado las distintas ramas.

Buenas prácticas: Nombrar ramas, mantener ramas cortas y específicas

Una de las principales recomendaciones es nombrar las ramas de forma clara, además de mantenerlas cortas y específicas en cuanto a lo que hacen.

Nombrar las ramas de manera coherente hace más fácil la colaboración entre los miembros del equipo. Los nombres deben reflejar el propósito o funcionalidad de la rama, para poder ver rápidamente en qué se está trabajando. Se aconseja seguir una convención de nombres predefinida. Una convención común es utilizar un prefijo indicando el tipo de trabajo seguido de una descripción:

• feature/nueva-funcionalidad para desarrollar nuevas características.
• bugfix/correccion-error para corregir errores.
• hotfix/parche-critico para aplicar correcciones urgentes.
• release/version-1.2 para preparaciones de lanzamientos.

Por ejemplo, para crear una rama destinada a implementar una página de inicio, se puede utilizar:

git switch -c feature/pagina-inicio

Estas convenciones suelen utilizar barras inclinadas / o guiones - para separar categorías y descripciones. Además, se suelen usar letras minúsculas y evitar caracteres especiales o espacios que puedan causar problemas a veces.

Como cada rama debe estar enfocada en una sola tarea o funcionalidad se suelen mantener las ramas cortas y específicas. Por ejemplo, en lugar de incluir múltiples cambios en una sola rama, es más eficiente crear ramas separadas para cada tarea:

• feature/formulario-contacto para implementar un formulario de contacto.
• bugfix/error-validacion para corregir un problema en la validación de datos.
• improvement/mejora-rendimiento para optimizar el rendimiento.

Otros consejos para gestionar ramas:

• Eliminar ramas que ya han sido fusionadas y no se necesiten más, utilizando:

git branch -d nombre-rama

• Actualizar regularmente la rama con los últimos cambios de main para minimizar conflictos:

git switch nombre-rama
git merge main

• Evitar trabajar directamente en la rama main; en su lugar, utilizar ramas temáticas y fusionar los cambios cuando estén listos.

Además, para mantener un historial limpio, se recomienda hacer commits pequeños dentro de las ramas, centrándose en cambios atómicos. Así se ve de un vistazo qué cambios se han hecho y por qué.