3 Escenarios Comunes y Frustrantes
Cuando usas Git, tu historial de commits a veces puede volverse complejo sin que te des cuenta. Aquí tienes algunos escenarios clásicos que muchos desarrolladores han enfrentado.
Escenario 1: Crear una rama desde otra rama de funcionalidad por accidente
Se suponía que debías crear tu nueva rama de trabajo (mi-feature) desde la última versión de main, pero accidentalmente la creaste a partir de una rama en la que un colega está trabajando (dev-feature). Ahora tu Pull Request incluye commits que no tienen nada que ver con tu trabajo.
|
1 2 3 4 5 6 7 8 9 |
# [Estado del Problema] * commit C (HEAD -> mi-feature) * commit B * commit A (dev-feature) <-- No debería haber creado la rama desde aquí | * Último main (main) |/ * ... |
Escenario 2: Mezclar múltiples funcionalidades en una sola rama
Mientras trabajabas en una rama (rama-de-trabajo), te das cuenta de que los commits C y D en realidad pertenecen a una funcionalidad completamente diferente (nueva-idea). Quieres separar limpiamente solo estos dos commits en una nueva rama.
|
1 2 3 4 5 6 7 8 9 10 |
# [Estado del Problema] * commit E (HEAD -> rama-de-trabajo) * commit D ┓ * commit C ┛ <-- Quiero separar solo estos dos * commit B * commit A * Último main (main) * ... |
Escenario 3: Empezar un trabajo nuevo sobre una rama desactualizada
Comenzaste un nuevo trabajo (trabajo-nuevo) en una rama que creaste hace meses (feature-antigua). Mientras tanto, la rama main ha evolucionado significativamente, y tus nuevos commits ahora están sobre un historial muy antiguo.
|
1 2 3 4 5 6 7 8 9 10 11 |
# [Estado del Problema] * commit Y (HEAD -> trabajo-nuevo) * commit X | * Un main mucho más reciente (main) | | * ... | |/ | * commit B (feature-antigua) <-- Base desactualizada |/ * Un commit antiguo de main |
Todos estos problemas se pueden resolver con git rebase --onto.