Deja de crear PRs monstruosas que hacen llorar a quien revisa. Así es como las y los seniors estructuran su trabajo para revisiones ultrarrápidas y cero conflictos de merge.
Resumen práctico - lo único que necesitas: 1 apila tus ramas: git checkout feature foundation; git checkout -b feature api layer. 2 cuando la PR base haga merge: git checkout feature api layer; git rebase main; git push --force-with-lease. 3 listo, en serio.
Por qué tu flujo actual está roto y cómo arreglarlo: hoy te pasa esto: 47 archivos cambiados y miles de líneas nuevas, la persona revisora se rinde a los 10 minutos, conflictos de merge infernales y un LGTM que no es una revisión real. La solución es el branch stacking o ramas apiladas, que convierte todo eso en 3 a 5 PRs enfocadas, cada PR representa una idea clara, quienes revisan entienden el código y los merges ocurren en minutos.
Estrategia de apilado que funciona: jerarquía de ramas ejemplo: main - feature database setup - feature api endpoints - feature authentication - feature error handling. Abre tu stack de PRs así: PR 1 de feature database setup hacia main, PR 2 de feature api endpoints hacia feature database setup, PR 3 de feature authentication hacia feature api endpoints, PR 4 de feature error handling hacia feature authentication.
Paso a paso para dominar el stacking fase 1 crear tu stack: comienza desde main y crea feature database setup, trabaja, commitea y sube. Luego desde feature database setup crea feature api endpoints, trabaja y sube. Continúa desde feature api endpoints para crear feature authentication, y así sucesivamente.
Fase 2 abre PRs estratégicas: en el UI de tu forja define como base la rama anterior y no main. Así la PR muestra solo los cambios nuevos y quien revisa ve difs limpios y enfocados.
Fase 3 el baile del rebase cuando vayan haciendo merge las PRs base: cambia a tu siguiente rama, rebasea contra main con git rebase main y después actualiza el remoto con git push --force-with-lease. Magia: la PR se actualiza y ahora muestra un diff limpio contra main.
Consejos pro que marcan la diferencia: nombra tus ramas como si contaras una historia. Evita nombres genéricos como feature updates o feature fixes. Prefiere nombres con intención como feature user auth foundation, feature payment processing core, feature notification system. Así todos entienden el objetivo.
El push forzado que no rompe todo: usa siempre --force-with-lease en lugar de --force. El primero es seguro porque no pisa cambios remotos que no has visto, el segundo es peligroso.
Reglas de oro: 1 una rama un concepto, si no puedes explicarla en una frase divídela. 2 apila de forma lógica, cada rama debe construir sobre la anterior. 3 rebase en lugar de merge para mantener el historial limpio. 4 commits pequeños, tu yo del futuro te lo agradecerá.
Solución de problemas rebase con conflictos: resuelve los conflictos en tu editor, añade los archivos resueltos con git add . y continúa con git rebase --continue. Si rebasaste la rama equivocada, busca el commit anterior con git reflog y vuelve atrás con git reset --hard HEAD@n ajustando n según corresponda. Si tu PR muestra demasiados commits, probablemente elegiste la base incorrecta, corrígelo en la configuración de la PR.
Resultados que se notan: antes del stacking promedio de revisión 2 a 3 días, conflictos de merge cada semana y calidad de código justita. Después del stacking promedio de revisión 2 a 3 horas, conflictos prácticamente eliminados y revisiones de verdad que mejoran la calidad.
Tarjeta de referencia rápida: crear rama apilada git checkout rama anterior y git checkout -b nueva rama. Tras el merge de la PR git checkout tu rama y git rebase main. Actualizar remoto git push --force-with-lease. Resolver conflictos de rebase git add . y git rebase --continue. Emergencias git reflog y git reset --hard HEAD@n.
Tus próximos pasos: pruébalo hoy, toma tu feature actual y divídela en 2 o 3 partes lógicas. Empieza en pequeño con un stack de 2 ramas. Mide el éxito comparando tiempos de revisión antes y después. Comparte el enfoque con tu equipo.
Conclusión: las PRs apiladas no son solo un flujo de trabajo, son un superpoder. Una vez lo domines no volverás a las PRs monstruo.
En Q2BSTUDIO aplicamos este enfoque a diario para entregar software a medida y aplicaciones a medida con ciclos de revisión ágiles, sin sorpresas y con calidad de nivel empresarial. Somos una empresa de desarrollo de software especialista en inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA y power bi. Si buscas un partner que entregue valor rápido y seguro, descubre nuestro enfoque en desarrollo de aplicaciones y software a medida y acelera tu roadmap con un flujo de trabajo que hace que las revisiones sean un placer.