3 Common & Frustrating Scenarios
When using Git, your commit history can sometimes become unintentionally complex. Here are some classic scenarios that many developers have faced.
Scenario 1: Accidentally Branched from Another Feature Branch
You were supposed to create your new work branch (my-feature) from the latest main, but you accidentally branched off a colleague’s work-in-progress branch (dev-feature). Now your Pull Request includes commits that have nothing to do with your work.
|
1 2 3 4 5 6 7 8 9 |
# [Problematic State] * commit C (HEAD -> my-feature) * commit B * commit A (dev-feature) <-- Shouldn't have branched from here | * Latest main (main) |/ * ... |
Scenario 2: Mixed Multiple Features in a Single Branch
While working on a branch (work-branch), you realize that commits C and D are actually for a completely different feature (new-idea). You want to cleanly separate just these two commits into a new branch.
|
1 2 3 4 5 6 7 8 9 10 |
# [Problematic State] * commit E (HEAD -> work-branch) * commit D ┓ * commit C ┛ <-- Want to separate only these two * commit B * commit A * Latest main (main) * ... |
Scenario 3: Started New Work on an Outdated Branch
You started some new work (new-work) on a branch you created months ago (old-feature). Meanwhile, the main branch has evolved significantly, and your new commits are now sitting on top of a very old history.
|
1 2 3 4 5 6 7 8 9 10 11 |
# [Problematic State] * commit Y (HEAD -> new-work) * commit X | * A much newer main (main) | | * ... | |/ | * commit B (old-feature) <-- Outdated base |/ * An old commit from main |
All of these problems can be solved with git rebase --onto.