Git para equipos pequeños de desarrollo web: flujo simple

Por /

Para equipos pequeños de desarrollo web el flujo más eficiente es trabajar sobre una rama principal (main), crear ramas cortas para cada tarea, revisar mediante pull requests y fusionar con merge commits. Este enfoque mantiene el historial limpio y es fácil de seguir incluso cuando solo sois dos o tres personas.

La estructura de ramas que funciona

Usamos dos ramas permanentes: main y develop. La rama main siempre refleja lo que está en producción. La rama develop integra las funcionalidades terminadas antes de subirlas a producción.

Para cada tarea (corrección, nueva funcionalidad, mejora) creamos una rama con nombre descriptivo desde develop. Cuando terminamos, abrimos un pull request hacia develop. Una vez revisado y aprobado, se fusiona y se borra la rama.

git checkout develop
git pull origin develop
git checkout -b fix/login-error
# ... trabajo ...
git add .
git commit -m "fix: corrige error de login con credenciales vacías"
git push origin fix/login-error

Convención de commits clara y útil

El historial solo sirve si se entiende. Usamos el formato convencional:

  • feat: nueva funcionalidad
  • fix: corrección de errores
  • refactor: cambios que no añaden ni corrigen funcionalidad
  • style: cambios de formato, espacios, etc.
  • chore: tareas de mantenimiento, actualización de dependencias

Ejemplos reales que usamos a diario:

feat: añade filtro por precio en la lista de productos
fix: corrige cálculo de impuestos en pedidos con cupón
refactor: simplifica consulta SQL de obtención de categorías
chore: actualiza composer.lock a versiones compatibles

El mensaje debe estar en imperativo y en español. Máximo 50 caracteres en la primera línea y, si hace falta, una descripción más detallada debajo.

Etiquetas de versión (tags)

Cuando subimos a producción creamos una etiqueta anotada. Es la única forma fiable de saber exactamente qué código está en cada despliegue.

git checkout main
git merge --no-ff develop
git tag -a v2.3.1 -m "Versión 2.3.1 - Corrección de carrito y mejora de velocidad"
git push origin main
git push origin v2.3.1

Usamos versioning semántico: vMAJOR.MINOR.PATCH. Incrementamos el número de versión según el tipo de cambio.

Qué nunca debe subir al repositorio

Hay archivos que deben estar en el .gitignore desde el primer día. No hay excusa para subirlos.

# WordPress
wp-config.php
wp-content/uploads/
wp-content/cache/
wp-content/upgrade/

# Prestashop y WooCommerce
config/settings.inc.php
var/cache/
var/logs/

# Dependencias
/vendor/
/node_modules/

# Archivos de entorno
.env
.env.local

# IDE y sistemas operativos
.idea/
.vscode/
*.log
.DS_Store
Thumbs.db

Para el wp-config.php es buena práctica tener un wp-config-sample.php con los valores por defecto y las constantes importantes documentadas.

Flujo completo de una tarea

  1. Actualizas develop
  2. Creas tu rama (feature/nueva-pasarela o fix/error-404)
  3. Trabajas y haces commits claros
  4. Subes la rama y abres pull request
  5. Alguien del equipo revisa el código
  6. Se fusiona en develop mediante merge commit
  7. Cuando todo está probado en staging, se fusiona develop en main
  8. Se crea tag de versión

Despliegue básico sin complicaciones

El método más sencillo y fiable para equipos pequeños es desplegar mediante SSH con rsync o git pull directo en el servidor.

En el servidor de producción tenemos un usuario dedicado y un post-receive hook o un script sencillo:

#!/bin/bash
cd /var/www/tienda
unset GIT_WORK_TREE
git pull origin main
composer install --no-dev --optimize-autoloader
wp theme build || true
echo "Despliegue completado - $(date)"

Antes de tocar producción siempre hacemos:

  • Pull completo de main
  • Backup de base de datos y archivos importantes
  • Instalación de dependencias sin dev
  • Limpieza de cachés

Buenas prácticas que evitamos dolores de cabeza

Rebase solo en tus ramas locales antes de abrir el pull request. Nunca rebaseas main ni develop una vez que otros han trabajado sobre ellas.

Los merge commits se dejan tal cual. No uses --no-ff solo por estética; úsalo cuando realmente quieras preservar el contexto de la rama.

Revisa los pull requests aunque el equipo sea pequeño. Cuatro ojos siempre ven más que dos, especialmente en temas de seguridad y rendimiento.

Configura git para que use tu nombre y email correctamente desde el primer día:

git config --global user.name "Carlos Pérez"
git config --global user.email "[email protected]"

Y activa los aliases que realmente usas:

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.lg "log --oneline --graph --decorate"

Este flujo no es el más sofisticado del mundo, pero lleva años funcionando sin dramas en equipos de tres a seis desarrolladores. Cumple con lo que realmente necesitamos: control, trazabilidad y velocidad a la hora de poner cambios en producción.

Una vez que todos siguen las mismas normas, Git deja de ser una fuente de estrés y se convierte en lo que debe ser: una herramienta fiable que documenta lo que hacemos.

Scroll al inicio