Branches y versionado

Naming conventions y workflow para el versionado de código en proyectos con fees.

🌿 Nomenclatura de branches

Para proyectos con fees

Al trabajar en proyectos facturables, crear branches con el número de ticket correspondiente:

Formato: [tipo]/[número-ticket]

Tipos de branch:

  • feature/ - Nueva funcionalidad
  • fix/ - Bug fixes
  • hotfix/ - Fixes urgentes
  • refactor/ - Refactoring de código
  • docs/ - Documentación

Ejemplos de nomenclatura

# Nuevas funcionalidades
feature/20    # Para ticket #20
feature/35    # Para ticket #35

# Bug fixes
fix/10        # Fix para issues en ticket #10
fix/42        # Fix para bug reportado en ticket #42

# Hotfixes urgentes
hotfix/67     # Fix urgente para ticket #67
hotfix/89     # Fix crítico para ticket #89

# Refactoring
refactor/15   # Refactor relacionado con ticket #15
refactor/28   # Code cleanup para ticket #28

🔄 Workflow de desarrollo

Proceso estándar

# 1. Crear branch desde main/develop
git checkout main
git pull origin main
git checkout -b feature/20

# 2. Desarrollo y commits
git add .
git commit -m "feat: implement hero section functionality"
git commit -m "feat: add responsive breakpoints"
git commit -m "fix: resolve layout issue on mobile"

# 3. Push y PR
git push origin feature/20
# Crear Pull Request en GitHub/GitLab

# 4. Code review y merge
# Review por líder técnico
# Merge a main/develop

Convenciones de commits

Formato: [tipo]: [descripción breve]

Tipos principales:

  • feat: - Nueva funcionalidad
  • fix: - Bug fix
  • refactor: - Refactoring sin cambio de funcionalidad
  • style: - Cambios de styling/formato
  • docs: - Documentación
  • test: - Tests
  • chore: - Tareas de mantenimiento

Ejemplos:

feat: implement homepage hero section
fix: resolve mobile navigation overflow
refactor: extract reusable button component
style: update color scheme to match designs
docs: add README for component usage
test: add unit tests for contact form
chore: update dependencies to latest versions

🔗 Linking tickets y código

En commits

Referenciar ticket en commits:

En Pull Requests

Template de PR:

## Ticket #20 - Homepage Hero Section

### 📋 Descripción

Implementación del hero section de la homepage según diseños aprobados.

### ✅ Cambios incluidos

- [x] Hero section layout desktop
- [x] Responsive adaptation mobile
- [x] CTA button functionality
- [x] Background video integration

### 🧪 Testing

- [x] Manual testing en Chrome, Safari, Firefox
- [x] Mobile testing en iOS y Android
- [x] Performance testing con Lighthouse

### 📎 Referencias

- **Ticket:** #20
- **Figma:** [Link a diseños]
- **Staging:** [URL para testing]

### 📝 Notas para reviewer

- Video background requiere fallback image
- CTA button usa analytics tracking

🔄 Hotfixes y rollbacks

Proceso de hotfix

# 1. Crear hotfix branch desde main
git checkout main
git checkout -b hotfix/critical-bug-fix

# 2. Fix rápido
git commit -m "hotfix: resolve critical payment issue"

# 3. Deploy urgente
git push origin hotfix/critical-bug-fix
# Deploy directo a producción si es crítico

# 4. Merge back a main y develop
git checkout main
git merge hotfix/critical-bug-fix
git checkout develop
git merge hotfix/critical-bug-fix

Rollback strategy

# Rollback a tag anterior
git checkout v1.1.0
git checkout -b rollback-emergency
git push origin rollback-emergency

# O revert commits específicos
git revert [commit-hash]
git push origin main

🎯 Best practices

Para developers

  1. 🔗 Always link tickets: Cada branch debe corresponder a un ticket
  2. 📝 Descriptive commits: Commits claros y específicos
  3. 🔍 Small PRs: Pull requests focalizados y reviewables
  4. 🧹 Clean history: Rebase/squash cuando sea apropiado
  5. 📋 Update tickets: Mantener tickets actualizados con progress

Para code reviewers

  1. ⚡ Timely reviews: Responder dentro de 24h
  2. 🎯 Focus on impact: Priorizar issues que afectan funcionalidad
  3. 📚 Knowledge sharing: Usar reviews para enseñar/aprender
  4. ✅ Test functionality: No solo review código, probar funcionalidad
  5. 📖 Check documentation: Validar que documentación esté actualizada

🌿 Un buen sistema de branching y versionado facilita la colaboración y reduce los riesgos en cada deploy.