Flujo de trabajo con GitHub: pull requests, revisiones e integración segura

El ciclo de contribución en GitHub (de tu rama a producción)

En GitHub, el flujo de trabajo típico para colaborar se centra en la pull request (PR): una propuesta de integrar cambios desde una rama (feature/bugfix) hacia una rama objetivo (por ejemplo, main o develop). La PR habilita conversación, revisión, checks automáticos (CI) y una fusión controlada.

Guía práctica paso a paso

• 1) Crear una rama para el cambio: crea una rama con un nombre descriptivo (por ejemplo, feature/login-rate-limit o fix/null-pointer). Trabaja ahí para mantener aislado el cambio.
• 2) Hacer commits coherentes: agrupa cambios relacionados. Evita “mega-commits” con refactors + feature + tests mezclados. Si necesitas reordenar o compactar commits antes de abrir la PR, hazlo localmente.
• 3) Publicar la rama en GitHub: sube tu rama al remoto para que GitHub pueda crear la PR y ejecutar checks.
• 4) Abrir la pull request: elige la rama base (destino) y la rama compare (tu rama). Completa título y descripción con contexto.
• 5) Recibir revisión: revisores comentan líneas, piden cambios o aprueban. Los checks (tests, linters) deben pasar.
• 6) Ajustar commits y actualizar la PR: aplica feedback con nuevos commits o reescribiendo commits localmente (según la política del equipo) y vuelve a subir cambios.
• 7) Fusionar de forma segura: elige el método de integración (merge commit, squash o rebase merge) acorde al contexto y reglas del repositorio.

Qué hace que una pull request sea “de calidad”

Una PR de calidad reduce el tiempo de revisión, baja el riesgo de bugs y deja un historial útil. Piensa en la PR como una unidad de entrega: debe ser entendible, verificable y acotada.

Criterios recomendados

• Descripción clara: explica el problema, la solución y el porqué. Incluye enlaces a issue/ticket si existe.
• Alcance acotado: una PR debería resolver una cosa. Si aparecen cambios no relacionados (formateo masivo, refactor grande), sepáralos.
• Evidencia cuando aplique: capturas (UI), logs relevantes, salida de comandos, o pasos de reproducción. En backend, puede ser útil incluir ejemplos de request/response o métricas.
• Commits coherentes: commits con intención clara (por ejemplo: “Agregar validación X”, “Agregar tests para X”, “Ajustar mensaje de error”). Evita commits “WIP” al final si el equipo exige limpieza.
• Checklist de verificación: pruebas locales ejecutadas, migraciones, impacto en configuración, compatibilidad, etc.

Plantilla breve de descripción (ejemplo)

## Qué cambia
- Agrega rate limit al endpoint /login
- Registra intentos fallidos para auditoría

## Por qué
- Evitar ataques de fuerza bruta

## Cómo probar
1. Ejecutar: ...
2. Llamar: POST /login con credenciales inválidas 6 veces
3. Verificar: respuesta 429 y log 'rate_limited'

## Evidencia
- Captura del panel / logs adjuntos

## Notas
- No hay cambios en DB

Revisiones en GitHub: cómo leer y responder feedback

La revisión no es un examen: es un mecanismo para mejorar calidad y compartir contexto. En GitHub verás comentarios por línea, sugerencias, conversaciones y estados (Approved / Changes requested).

Buenas prácticas al responder

• Responde con intención: si aplicas el cambio, indica “Listo, ajustado en el commit X”. Si no estás de acuerdo, explica el motivo y ofrece alternativa.
• No mezcles temas: si el revisor pide dos cambios distintos, intenta resolverlos en commits separados (facilita revisar).
• Evita discusiones largas en código: si el tema es de diseño, resume en un comentario y, si hace falta, mueve la discusión a un issue o documento.

Actualizar una PR: commits de corrección vs reescritura (rebase) antes de subir

Cuando recibes feedback, tienes dos estrategias comunes para actualizar la PR:

• Agregar commits de corrección: creas uno o varios commits nuevos que ajustan lo pedido. Ventaja: es simple y transparente. Desventaja: puede ensuciar el historial si hay muchos “fix review”.
• Reescribir commits localmente (rebase interactivo) y forzar push: reorganizas, editas o “squasheas” commits para que queden limpios y con intención clara. Ventaja: historial más legible. Desventaja: requiere cuidado porque reescribes historia (normalmente se hace solo en tu rama de PR).

Flujo recomendado para rebase local antes de actualizar la PR

Útil cuando quieres: (a) dejar commits más coherentes, (b) resolver conflictos localmente, (c) actualizar tu rama con la base antes de fusionar.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

# 1) Trae cambios del remoto
git fetch origin

# 2) Rebase de tu rama sobre la rama base actualizada (ej: main)
git rebase origin/main

# 3) Si necesitas reordenar/compactar commits (opcional)
git rebase -i origin/main

# 4) Ejecuta tests/local checks
# (comando según tu proyecto)

# 5) Actualiza la rama en GitHub (si reescribiste historia)
git push --force-with-lease

Nota: usa --force-with-lease en lugar de --force para reducir el riesgo de sobrescribir trabajo ajeno si alguien más empujó a tu rama.

Modelos de integración en GitHub: merge commit, squash merge y rebase merge

Al fusionar una PR, GitHub suele ofrecer varios métodos. Elegir bien afecta el historial, la trazabilidad y la experiencia de depuración.

Recomendaciones rápidas según contexto

• Proyecto con historial “audit-friendly” (necesitas ver ramas y puntos de integración): suele preferirse merge commit.
• Proyecto que prioriza historial simple (cada PR = un commit en main): suele preferirse squash merge.
• Proyecto que quiere historial lineal pero detallado (commits bien curados): suele preferirse rebase merge.

Integración segura: checks, aprobaciones y reglas de protección

GitHub permite configurar reglas para que una PR no se pueda fusionar hasta cumplir condiciones. Aunque la configuración la define el equipo, como contribuidor debes entender qué mirar:

• Checks de CI: tests, linters, build, análisis estático. Si fallan, corrige antes de pedir re-revisión.
• Revisiones requeridas: número mínimo de aprobaciones o revisores específicos (CODEOWNERS).
• Rama actualizada: algunas reglas exigen que tu rama esté al día con la base antes de fusionar.

Cómo actuar cuando la PR exige “estar al día”

Si la rama base avanzó, actualiza tu rama antes de fusionar. En muchos equipos se prefiere rebase para mantener linealidad, pero depende de la política:

git fetch origin
# Opción A: rebase sobre la base
git rebase origin/main

# Opción B: merge desde la base (si el equipo lo permite)
git merge origin/main

# Luego
git push  # o --force-with-lease si hiciste rebase

Resolver conflictos durante una PR (cuando sea necesario)

Si aparecen conflictos, puedes resolverlos localmente (recomendado para tener control y ejecutar pruebas) o, en algunos casos, desde la interfaz de GitHub cuando el conflicto es simple y GitHub lo permite.

Resolución local (flujo típico)

git fetch origin
git rebase origin/main   # o git merge origin/main
# Git se detendrá en conflictos
# 1) Abre archivos en conflicto y resuelve marcadores
# 2) Marca como resuelto
git add ruta/al/archivo
# 3) Continúa
git rebase --continue    # si estabas en rebase
# o
git commit               # si estabas en merge

# Ejecuta tests y sube cambios
git push --force-with-lease  # si rebase
# o
git push                  # si merge

Resolución desde GitHub (cuando aplique)

• Úsalo solo si el conflicto es pequeño y entiendes perfectamente el cambio.
• Después, vuelve a ejecutar checks (GitHub los disparará al actualizar la PR) y revisa que no se haya roto nada.

Ejemplo completo: de PR a merge con feedback

Escenario

Implementas una validación nueva y un test. Abres PR. El revisor pide: (1) renombrar una función, (2) mejorar el mensaje de error, (3) ajustar un test.

Aplicación del feedback con commits separados

# En tu rama de la PR
# Cambios 1 y 2
git add archivo1 archivo2
git commit -m "Renombrar función y mejorar mensaje de error"

# Cambio 3
git add tests/
git commit -m "Ajustar test para nuevo mensaje"

git push

Alternativa: limpiar commits antes de fusionar (si el equipo lo pide)

git fetch origin
git rebase -i origin/main
# En el editor: reordena/squash/fixup para dejar 2-3 commits con intención

git push --force-with-lease

Luego solicita re-revisión, verifica que los checks estén en verde y elige el método de integración acordado por el repositorio.