If it wasn’t for this visualization tool, I’d never grasp Git concepts. Today’s tip follows the Git documentation for Rebasing

Suppose you’re experimenting locally on one branch (called creatively, `experiment`) and you want to rebase back onto master. For now, let’s imagine that master is a remote that you’ve cloned from somewhere. When the time comes to push those changes back, you don’t want your local Git history* to show merges commits from your local explorations. You’re going for the linear “look! I got it all right on the first try” history.

First, you’ll want to make sure you’re on the `experiment` branch.

Next, you’ll use the command to rebase your current branch (experiment) onto master. I silently verbalize “onto” as the preposition to help me understand what the rebase command is going to do.

$ git rebase master

Note how the rebase results in new commit IDs. If you take nothing else away today, note this:

Whenever you do a rebase, you are changing history.

more on this later.

Now to “finish the rebase.” This is where I’m so grateful for this visualization tool. Before seeing what was happening, I’d thought everything would be done for me.  Thanks to the visualization I can see based on the master pointer that I need to merge the experiment branch.

$ git checkout master

$ git merge experiment

This last step should look familiar. The rebase makes our history look like all of our changes were based on the last commit on master. This would be the equivalent of being on the last commit of master, checking out a branch, making commits, and then performing a fast-forward merge from master.

There are just so many moving parts here that a visualization tool helps greatly.

*I mentioned previously about doing rebases on your local git history. The rule of rebasing is you should never do it if those commits have been previously pushed or shared somewhere, since you’re changing history, and Git hates it when you change history. There are ways out of it, but I’m saving that to explore in October timeframe.

A good recap from the documentation (last sentence, of course. always amazing how the most important info is often found at the very end of a document or email. a trick someone taught me once is to write out what you want to say, and the reverse the order of the paragraphs. I guess this blog post is proof of concept 😉 since I’m leaving the most important piece at the bottom!)

In general the way to get the best of both worlds is to rebase local changes you’ve made but haven’t shared yet before you push them in order to clean up your story, but never rebase anything you’ve pushed somewhere.

• Git(Hub) Tip of the Day 2017