A coworker recently explained rebasing in a way that made it make sense to me for the first time: it's just pretending you branched off of better code than you actually did.
The usual diagram of rebasing looks something like this:
This is clear to me when I have two branches--a main/master branch and a second branch with my new feature--but that's rarely how a repo is being used. There's usually multiple feature and bug branches being worked on simultaneously--often by different team members. When I'm asked to rebase due to changes made to main, this diagram makes it look destructive and scary. To be clear, it IS destructive in the sense that it fundamentally changes the history of your branch, but the consequences aren’t necessarily as scary as they appear.
For me at least, I found it helpful to just ignore the diagram and think of it like this:
First, I made my feature off of main. Meanwhile, someone else made a significant improvement to main--an important bug fix maybe. I could merge main into my branch and leave a paper trail, but if we're confident in these changes, why not keep my commits clean and pretend like they were always there? Rebasing essentially tells my feature branch, hey, let's just act like I was working off of this new and improved main branch all along.
Top comments (0)