Flujo de Trabajo Profesional con Git y GitHub Professional Workflow with Git and GitHub

1. Estrategia de ramas: GitHub Flow vs Git Flow1. Branch Strategy: GitHub Flow vs Git Flow

Para la mayoría de equipos modernos con deploys frecuentes, GitHub Flow es la mejor opción: solo una rama principal (main) y ramas de feature de corta duración: For most modern teams with frequent deployments, GitHub Flow is the best option: one main branch (main) and short-lived feature branches:

# Crear una rama de feature
git checkout -b feat/user-authentication

# Trabajar, commitear y hacer push
git add .
git commit -m "feat(auth): add JWT login endpoint"
git push -u origin feat/user-authentication

# Abrir Pull Request en GitHub → Code Review → Merge → Deploy
# Eliminar la rama después del merge
git branch -d feat/user-authentication

Git Flow (con ramas develop, release/*, hotfix/*) es adecuado para productos con ciclos de release largos y múltiples versiones en producción. Para proyectos web modernos con CI/CD, añade complejidad innecesaria. Git Flow (with develop, release/*, hotfix/* branches) suits products with long release cycles and multiple versions in production. For modern web projects with CI/CD, it adds unnecessary complexity.

2. Conventional Commits — mensajes que documentan2. Conventional Commits — Messages That Document

El estándar Conventional Commits hace que el historial de Git sea legible para humanos y máquinas. Permite generar changelogs automáticos y calcular versiones semánticas: The Conventional Commits standard makes the Git history readable for both humans and machines. It enables automatic changelog generation and semantic version calculation:

# Formato: <tipo>(<scope>): <descripción>

feat(auth): add OAuth2 Google login
fix(api): handle null response from payment gateway
docs(readme): update deployment instructions
refactor(user): extract UserService from UserController
test(auth): add unit tests for JWT validation
chore(deps): bump express from 4.18 to 4.19

Los tipos principales son: feat (nueva funcionalidad), fix (corrección de bug), docs, refactor, test, chore. Un commit con BREAKING CHANGE: en el footer dispara un bump de versión mayor. The main types are: feat (new feature), fix (bug fix), docs, refactor, test, chore. A commit with BREAKING CHANGE: in the footer triggers a major version bump.

3. Pull Requests efectivos3. Effective Pull Requests

Un buen PR es pequeño y enfocado. Reglas prácticas para PRs de calidad: A good PR is small and focused. Practical rules for quality PRs:

• Máximo 400 líneas de cambio por PR (los revisores no leen PRs gigantes)Max 400 lines of change per PR (reviewers don't read giant PRs)
• Un PR debe hacer una sola cosa bienA PR should do one thing well
• Incluir descripción + capturas de pantalla si hay cambios de UIInclude description + screenshots if there are UI changes
• Enlazar el issue o tarea relacionada (Closes #42)Link the related issue or task (Closes #42)
• Responder todos los comentarios antes de solicitar re-reviewRespond to all comments before requesting a re-review

4. Rebase interactivo para historial limpio4. Interactive Rebase for a Clean History

Antes de mergear una rama, usa git rebase -i para consolidar commits intermedios ("squash") y reescribir mensajes ambiguos: Before merging a branch, use git rebase -i to squash intermediate commits and rewrite ambiguous messages:

# Rebase los últimos 4 commits de forma interactiva
git rebase -i HEAD~4

# En el editor, cambia "pick" por:
# s (squash) — une al commit anterior
# r (reword) — cambia solo el mensaje
# d (drop) — elimina el commit

# Actualizar la rama en el remoto (solo en ramas propias, nunca en main)
git push --force-with-lease origin feat/mi-feature

5. GitHub Actions — CI mínimo viable5. GitHub Actions — Minimum Viable CI

Un workflow básico que ejecuta linting y tests en cada PR evita que código roto llegue a main: A basic workflow that runs linting and tests on every PR prevents broken code from reaching main:

# .github/workflows/ci.yml
name: CI
on:
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage

ConclusiónConclusion

Un buen flujo Git no es burocracia: es la diferencia entre un historial que documenta la evolución del producto y un historial que no le dice nada a nadie. Conventional Commits + PR reviews + CI básico son el mínimo para cualquier equipo serio. A good Git workflow isn't bureaucracy: it's the difference between a history that documents product evolution and one that tells nobody anything. Conventional Commits + PR reviews + basic CI are the minimum for any serious team.

¿Necesitas asesoría para establecer un flujo de trabajo Git en tu equipo de desarrollo en Colombia? Contáctame. Need advice on establishing a Git workflow for your development team? Contact me.