Flujo de trabajo Git para desarrolladores PHP: guía práctica

Flujo de trabajo Git para desarrolladores PHP: del caos al orden (y viceversa)

¿Alguna vez has subido código a master un viernes por la noche, rezando para que todo funcione? ¿O te has topado con problemas con composer.lock cuando todo se rompió después de un merge? Bienvenido al club. Git no es solo un sistema de control de versiones, es tu herramienta diaria. Pero sin un flujo de trabajo adecuado, incluso el mejor código PHP se convierte en una calabaza.

En este artículo, analizaremos el flujo de trabajo Git para desarrolladores PHP que realmente funciona: desde la elección de la estrategia de ramificación hasta el despliegue. Sin rodeos, solo código, ejemplos y trucos. ¡Vamos allá!

1. Elige tu estrategia: Git Flow vs. Trunk-Based

El debate entre git flow y el desarrollo trunk-based es más largo que la historia de los frameworks PHP. Pero para la mayoría de los proyectos PHP (especialmente los legacy en Symfony/Laravel), Git Flow sigue siendo el estándar de oro. ¿Por qué?

\n
• Aislamiento claro de funcionalidades, lanzamientos y hotfixes.
\n
• Control sobre lo que llega a producción.
\n
• Trabajo con composer — no es necesario fusionar la rama de desarrollo constantemente.
\n

Pero si tienes microservicios y CI/CD a tope, trunk-based también es una opción. Nosotros nos centraremos en el clásico.

2. Feature Branch: tu zona de pruebas

Cada nueva funcionalidad, una rama independiente. El nombre debe ser descriptivo: feature/PROJ-123-add-payment-gateway. Nada de fix-bug o new-stuff.

Ejemplo para empezar:

git checkout -b feature/PROJ-42-new-cache-system develop\ngit push origin feature/PROJ-42-new-cache-system

Mientras escribes código, no olvides composer. Si agregas una nueva dependencia, haz commit de composer.json y composer.lock juntos. Esto evitará que tus compañeros digan "¿por qué no me funciona a mí?"

composer require predis/predis\ngit add composer.json composer.lock\ngit commit -m "PROJ-42: Add predis for caching"

Importante: ¡no hagas commit de vendor/! Añádelo a .gitignore de inmediato.

3. Pull Request: code review sin dolor

Cuando la funcionalidad esté lista, crea un PR (o MR en GitLab) hacia develop. Aquí tienes una lista de verificación que salvará los nervios del revisor:

\n
• ✅ El código pasa phpcs y phpstan (nivel mínimo 6).
\n
• ✅ Se han escrito pruebas (PHPUnit, Pest).
\n
• ✅ Se ha actualizado composer.lock.
\n
• ✅ No hay conflictos con develop.
\n

Ejemplo de script de CI (GitHub Actions):

name: PHP CI\n\non:\n  pull_request:\n    branches: [ develop ]\n\njobs:\n  php-tests:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v3\n      - name: Install dependencies\n        run: composer install --no-interaction --prefer-dist\n      - name: Run PHPStan\n        run: vendor/bin/phpstan analyse src --level=6\n      - name: Run tests\n        run: vendor/bin/phpunit

Este flujo de trabajo para desarrolladores PHP automatiza la revisión del código incluso antes de que alguien mire el PR. Magia, ¿verdad?

4. Rama de lanzamiento: preparación para producción

Cuando tengas suficientes funcionalidades para un lanzamiento, crea release/x.y.z desde develop. Aquí corriges errores, actualizas el changelog y aumentas la versión en composer.json.

git checkout -b release/1.2.0 develop\n# corrige errores, actualiza la versión\nvim composer.json  # cambia "version": "1.2.0"\ngit commit -am "Bump version to 1.2.0"\n# fusiona en master y develop\ngit checkout master\ngit merge --no-ff release/1.2.0\ngit tag -a v1.2.0 -m "Release version 1.2.0"\ngit push origin master --tags

Observa el --no-ff. Esto conserva el historial de ramificación para que siempre sepas de dónde vino el código.