Develop Branch en Git — qué es, propósito y principios de funcionamiento

Qué es Develop Branch en Git

Develop Branch (rama de desarrollo) es una rama de larga duración en Git Flow que sirve como centro central para la integración de código de todos los desarrolladores. Las ramas feature se fusionan en ella después de completar el desarrollo y la revisión de código.

El código en develop siempre está en un estado listo para crear un lanzamiento, aunque aún no esté desplegado en producción. Esto significa que todas las funciones en develop han pasado revisión, pruebas y comprobaciones de integración, pero aún esperan su ciclo de lanzamiento.

A diferencia de main, donde cada versión de código es un lanzamiento, develop contiene un flujo continuo de cambios. Los commits en develop aparecen a medida que se fusionan las ramas feature, lo que puede ocurrir varias veces al día.

Según Vincent Driessen, 2010, develop es un elemento clave de un modelo de bifurcación exitoso, ya que separa el trabajo en borrador de las versiones listas para lanzamiento.

Diferencias entre develop y main branch

Comprender las diferencias entre develop y main es fundamental para un flujo de trabajo Git Flow adecuado. Estas ramas cumplen funciones diferentes y tienen distintos requisitos de estabilidad.

La separación en develop y main permite al equipo integrar continuamente nuevo código sin arriesgar la estabilidad de la versión de producción. Los desarrolladores pueden ver su código en develop inmediatamente después de la aprobación del PR, incluso antes del lanzamiento oficial.

Rol de develop en Git Flow

En el modelo Git Flow, develop ocupa un lugar central entre las ramas feature (fuente de cambios) y las ramas release (preparación para el lanzamiento). Comprender esta jerarquía es la base de una bifurcación efectiva.

• Feature → Develop — cada función completada se fusiona en develop mediante un Pull Request con revisión de código.
• Develop → Release — cuando se acumulan suficientes cambios para un lanzamiento, se crea una rama release desde develop.
• Release → Main + Develop — después de la preparación final, la rama release se fusiona en main (lanzamiento) y de vuelta en develop (correcciones de errores).
• Hotfix → Main + Develop — las correcciones críticas se crean desde main y se fusionan en ambas ramas.

Esta estructura garantiza que develop siempre contenga el código más reciente con todas las nuevas funciones, mientras que main contiene solo código de producción verificado. Esto es especialmente importante para proyectos móviles con ciclos de revisión largos en App Store y Google Play.

Relación de develop con otras ramas de Git Flow

Develop actúa como el enlace central entre las ramas feature, release y hotfix. Comprender las direcciones de fusión es esencial para prevenir conflictos y pérdida de commits.

Requisitos de calidad de código en develop

La calidad del código en develop debe ser alta, pero no absoluta. A diferencia de main, donde cada error significa una corrección urgente, develop permite imperfecciones menores que se corregirán antes del lanzamiento.

Requisitos mínimos para el código antes de fusionar en develop:

• Compilación — el código debe compilarse sin errores. Una compilación rota en develop bloquea el trabajo de todo el equipo.
• Pruebas unitarias — todas las pruebas existentes deben pasar. El código nuevo debe estar cubierto por pruebas al menos al 70%.
• Estilo de código — el código debe cumplir con los estándares de formato y nomenclatura aceptados por el equipo.
• Sin API obsoleta — no se permite el uso de métodos obsoletos en código nuevo.

Las comprobaciones automatizadas en el pipeline CI/CD deben ejecutarse en cada push a develop. Si la compilación se rompe, el desarrollador responsable debe solucionar el problema en una hora o revertir su commit.

Comprobaciones CI/CD para develop

Configurar GitHub Actions para develop garantiza que cada PR pase comprobaciones automatizadas antes de fusionarse. Un pipeline típico incluye compilación, pruebas y linting.

# GitHub Actions — verificación de develop después de la fusión
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

Reglas de fusión en develop

La fusión en develop debe seguir reglas estrictas para mantener la estabilidad de la rama de integración. Violar estas reglas provoca conflictos, compilaciones rotas y pérdida de tiempo del equipo.

• Solo mediante Pull Request — el push directo a develop está prohibido. Todos los cambios pasan por revisión de código.
• Mínimo una aprobación — el PR debe ser aprobado por al menos un desarrollador no involucrado en la tarea.
• Squash merge — se recomienda combinar todos los commits de la rama feature en uno al fusionar en develop para un historial limpio.
• PR actualizado — antes de fusionar, el PR debe estar actualizado con respecto al último commit de develop (rebase o merge).

La regla de PR actualizado es especialmente importante. Si una rama feature se creó hace una semana y develop ha avanzado 50 commits, la fusión directa podría provocar conflictos que es mejor resolver en el contexto del PR que en develop.

Protección de develop contra fusiones incorrectas

Las reglas de protección de rama son configuraciones a nivel de GitHub, GitLab o Bitbucket que evitan cambios incorrectos en develop. Garantizan que incluso un push accidental no rompa la rama de integración.

Reglas de protección recomendadas para develop:

• Requerir pull request — prohibir push directo a develop. Todos los cambios solo mediante PR.
• Requerir aprobaciones — mínimo 1-2 aprobaciones antes de fusionar el PR.
• Requerir verificaciones de estado — bloquear la fusión si el pipeline CI/CD no ha pasado.
• Requerir actualización — la rama del PR debe estar actualizada respecto a develop antes de fusionar.
• Restringir acceso de push — limitar los derechos de push a develop solo para desarrolladores senior.

Configurar la protección de develop toma 10 minutos pero previene semanas de inactividad relacionadas con una rama de integración rota. Para proyectos móviles con equipos multiplataforma, esto es especialmente relevante.

Ejemplos de comandos para trabajar con develop

Consideremos un día típico de un desarrollador: por la mañana actualiza develop, crea una nueva rama feature y, después de completar la tarea, fusiona los cambios de vuelta en develop.

# Sincronización matutina de develop
git checkout develop
git pull origin develop

# Creación de una nueva rama feature desde develop
git checkout -b feature/add-push-notifications

# Trabajando en la función...
git add . && git commit -m "Add FCM integration"

# Actualización de develop durante el desarrollo
git fetch origin develop
git rebase origin/develop

# Después de aprobar el PR — actualizar develop local
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

El comando git pull en develop realiza dos operaciones a la vez: git fetch (recupera nuevos commits del servidor) y git merge (los fusiona con la rama local). Para develop, este es el método estándar de sincronización.

Recuperación de develop después de una fusión rota

Si un código que rompió la compilación llega a develop, hay que actuar rápidamente. Cada hora de inactividad de develop es trabajo bloqueado para todo el equipo de desarrollo.

Si un código que rompió la compilación llega a develop, usa git revert para crear un nuevo commit que deshaga los cambios problemáticos. No uses git reset en develop — reescribe el historial que otros miembros del equipo ya tienen.

# Búsqueda del commit problemático
git log --oneline develop

# Cancelación del commit mediante revert (seguro)
git revert a1b2c3d

# Envío de la corrección al develop remoto
git push origin develop

# Ver cambios en un commit específico
git show a1b2c3d --stat