Rebasing is a topic that comes up all the time when using Git. Many times, rebasing results in having to do a force push, which makes some people wary of rebasing. No need to worry! Once you understand why a force push is necessary, and how to rebase responsibly, you’ll feel more comfortable.

So, what is rebasing, and how do you rebase in Git? Rebasing is simply taking changes that have been made somewhere else, incorporating them into your branch, and then replaying all of your changes on top of that new base.

You’re in fact, changing the commit history, which Doc taught us could have disastrous consequences. (Especially if you run into your future self.)

So, let’s throw on some Huey Lewis, listen to The Power of Love on repeat, and dive into an example featuring Back to the Future. And if you’re even considering using the CLI… Where we’re going, we don’t need the command line!

The Timeline

I made a new repo in GitKraken, a cross-platform Git GUI, featuring some main plot points from Back to the Future. First, Marty is sent back to 1985. You’ll see I created a new timeline branch that has a couple of commits representing the events that follow. Then, I pushed the timeline branch up to GitHub.

Marty is sent back in time where he encounters some highs and lows.

This timeline branch ultimately leads Marty successfully back to the future, and ends happily with Biff the bully waxing Marty’s dad’s BMW; plus Marty has a brand new Toyota 4×4. Yay! Everyone loves a happy ending!

However, back on master, there’s another change made where the Grays Sports Almanac has been added to the picture. (Uh oh….Biff is going to change the world into a very ugly place…)

If I rebase the timeline on top of master, (by dragging the timeline label on the left, on top of the master label, and selecting rebase timeline into master) GitKraken will replay all of my commits, on top of the last commit on master, in the same order.

As you’re probably aware, this action affects the future, and Biff becomes a philandering, billionaire casino owner and marries Marty’s mom. (Any resemblance to current presidential candidates is purely coincidental, but I digress.)

Biff has the opportunity to take over the world… and does.

Back on my remote timeline branch, you’ll see that I still have everything happening in the happy timeline, but locally we have a different commit history.

Therefore, GitKraken is not going to allow a simple push. Git only allows pushing new commits and can’t insert other commits into the Git history, which is why I have to do a force push. The force push literally replaces the remote branch with what we have locally.

Now, this is where some of the trouble comes in. If I replace my remote branch with what I have locally, this has the ability to overwrite other changes, and it’s exactly why a lot of people are reluctant to use rebasing.

‘Mom hydrates a pizza!’ is added.

Let’s say that other changes were made to my remote branch that I haven’t pulled in locally. So, on the remote timeline branch, Doc made another commit called ‘Mom Hydrates a Pizza!’, which doesn’t exist on my local timeline branch.

Now if I do a force push, whatever commits are not on the local branch will be lost, and we don’t get the hydrated pizza. In this case, I can cherry pick any new commits into my local timeline, and then do the force push.

I know, I know, this lands us with the dystopian timeline and ruins Marty’s happily ever after…

The Golden Rule of Rebasing

The Golden Rule of Rebasing reads: “Never rebase while you’re on a public branch.” This way, no one else will be pushing other changes, and no commits that aren’t in your local repo will exist on the remote branch. So then when you push, there’s no possibility of deleting data.

If my calculations are correct, when this baby hits 88 miles an hour, you’re gonna see some serious Git!!