Git Flow profesional: ramas, PRs y conflictos

Aprende a trabajar con Git y GitHub como en un entorno profesional: crea ramas seguras, escribe commits semánticos, abre pull requests, resuelve conflictos y documenta tu trabajo sin perder control. Con ejemplos reales y un enfoque directo, verás cómo evitar errores comunes y ganar velocidad colaborando.

¿Qué son Git y GitHub y cómo se conectan?

Git es un controlador de versiones distribuido creado por Linus Torvalds en 2005 para gestionar el código fuente de forma segura y eficiente. GitHub no es Git: es la plataforma social donde hospedas repositorios Git, haces pull requests, revisiones y automatizaciones. Piensa en Git como la herramienta y en GitHub como el espacio colaborativo donde se ve y valida el trabajo.

• Código local primero: el repositorio vive en tu máquina; sincronizas con remoto cuando haces push o pull.
• Ramas como flujo de trabajo: la rama principal (main o master) es el tronco; cada cambio viaja en su propia rama.
• GitHub como vitrina profesional: repos públicos, forks, issues y PRs muestran experiencia y proceso.

¿Cómo clonar e iniciar un repositorio con comandos clave?

• Clonar un repo remoto.

git clone <URL-del-repo>

• Inicializar un repo local y conectarlo a remoto.

git init
# agrega remoto si hace falta
git remote add origin <URL-del-repo>

• Flujo básico para subir cambios.

# ver estado
git status
# preparar cambios (todo o archivo específico)
git add .
# o: git add path/al/archivo
# commit con mensaje semántico
git commit -m "fix: ajustar margen en header"
# subir a remoto (HEAD toma la rama actual)
git push origin HEAD

• Evita subir compilados: usa .gitignore para ignorar carpetas o archivos generados.

¿Cuál es el flujo de ramas recomendado para colaborar?

Trabaja siempre en ramas. La rama principal no recibe cambios directos. Crea una rama por objetivo: fix para correcciones, feature para funcionalidades. Así reduces riesgos, ordenas el historial y facilitas el code review.

¿Cómo creo y trabajo una rama segura?

• Crear una rama descriptiva.

git checkout -b fix-header-size

• Hacer cambios y añadir solo lo necesario.

git add src/styles/header.css
git commit -m "fix: remover margin que impedía 100% de ancho"

• Sincronizar antes de subir: primero pull, luego push.

# trae cambios remotos antes de subir
git pull --rebase origin fix-header-size
# sube tu rama
git push origin HEAD

• Mensajes claros con commits semánticos y uso de "conventional comments" mencionados: usa tipos como fix o feature, y describe qué y por qué.
• Apóyate en IA del editor (p. ej., Cursor) para "generate commit message" cuando tenga contexto del cambio.

¿Cómo crear un pull request y pasar revisión?

• Abre un pull request desde tu rama hacia main (o la rama base que use la empresa: main, master o incluso root).
• Pide revisión: la persona revisor hace comentarios, aprueba o solicita ajustes.
• Al aprobarse, haz Merge del PR. Si la rama principal está protegida, solo usuarios con permisos podrán fusionar.
• Si te equivocas, usa Revert del PR: crea un nuevo PR que deshace ese cambio de forma limpia.

¿Qué conflictos y buenas prácticas debes dominar?

Los conflictos aparecen cuando dos ramas cambian las mismas líneas. Son normales. La clave es prevenir y saber resolverlos con criterio.

¿Cómo prevenir y resolver conflictos de forma práctica?

• Antes de push: ejecuta git pull para alinear tu rama con remoto.
• Si hay conflicto, GitHub muestra bloques en conflicto y qué difiere entre tu rama y main. Elige las líneas correctas, resuelve y confirma.
• Verifica local tras el merge: sincroniza y valida en tu entorno.

Buenas prácticas que elevan tu flujo diario:

• Protege la rama principal: obliga PRs y revisiones antes de fusionar.
• Nomenclatura descriptiva en ramas: que expliquen el objetivo.
• Historial como documentación: los commits y PRs cuentan la historia del código.
• Issues para gestión: registra tareas y bugs, crea ramas desde ahí y referencia en PRs.
• Revert seguro: deshace cambios problemáticos sin cirugías manuales.
• Automatización con GitHub Actions: corre tests, lint y deploy al detectar cambios en main.
• Ramas épicas para grandes features o microservicios: crea una rama intermedia (épica) y fusiona ramas pequeñas en ella antes de llevar todo a main. Reduce PRs gigantes y facilita revisiones por partes.
• Forks para contribuir a proyectos ajenos: copia el repo a tu cuenta y trabaja con PRs hacia el original.
• .gitignore bien configurado: no subas compilados ni artefactos.
• Herramientas de apoyo: GitHub Desktop para visualizar cambios; editores como Cursor con panel de cambios y generación de mensajes; Copilot para code review automatizado; "Cloud Code" para asistir en refactors sobre el contexto del proyecto.
• Credenciales: normalmente usas una cuenta por máquina; sobre múltiples cuentas, el ponente sugirió que podría aislarse con contenedores Docker por contexto, aunque no lo ha implementado.
• Conexión segura: configura llaves SSH en GitHub y enlaza tu Git local al remoto.

Comenta cómo nombras tus ramas, qué estrategia usas para PRs grandes y qué automatizaciones te han ayudado más en tu día a día.