Interactive Rebase

By now ooloo-bot should have approved your Content Container Pull Request. If you haven't done yet please go ahead and merge the PR.

Once you merge the PR the situation gets a bit more complicated. The main and the bottom-section branch both contain the code from the content-container branch you just merged. But because of the squash merge, they have different commits.

To get a better understanding let's have a look at the commit history again.

The current commit history

Before the merge we had two commits on the content-container branch, remember? Now that it is merged the two commits were squashed into a single commit on the main branch.

The problem is now that we still have the two commits from content-container inside the bottom-section branch. They are the purple commits in the below image. Only the orange commit actually belongs to the bottom-section branch.

Let's confirm that by quickly looking at the commit history of the main and bottom-section branches.

Note: you have to pull the latest changes from the main branch to your local repo first.

Why is this a problem?

We have commits in the bottom-section that don't belong there. You may ask: "So what? We'll squash the commits anyway. They won't appear in the main branch."

The problem becomes clear when you view the File changes in the Pull Request on GitHub.

See that GitHub highlighted the changes in the .content class as if they belonged to the Bottom Section PR? But we never touched the .content class in this PR. These changes originated from the content-container branch.

The reviewer might be confused: "Didn't I already review this code before?"

Now in a real team, you typically would have larger PRs with many more code changes. Your teammates would have to review parts of the code twice which is very time-consuming and annoying. They might even refuse to review the PR.

Better get rid of these two commits

Great idea. But how do we remove specific commits from our history?

This is where the git rebase command comes in again. It has a powerful option -i or --interactive which makes it a Swiss Army knife for editing the commit history.

Let's see how we would like our commit history to look like first. Instead of the current history

the cleaned-up version should look like this:

Here you don't see the purple commits that belonged to the content-container branch anymore. The corresponding code is now in the commit Content Container (#4).

That looks like a clean commit history.

Interactive Rebase

Altering the commit history is always a bit exciting. It may feel like working without a safety net since we change the history for good.

That's why it's again important to push the branch to have a backup in case something goes wrong.

Next, make sure you're on the bottom-section branch.

git checkout bottom-section

And finally, we run the magic command.

git rebase -i main

Once you run this command an editor will open inside your terminal.

Note: If you're unlucky the editor might be VIM. Nothing against VIM, it can be very powerful. But a lot of beginners don't even know how to close it again. I remember the first time I came in contact with VIM I thought I had to shut down my computer to exit!

If that's the case for you have a look here to end the nightmare and see this page to see how you can select another editor.

When you run the interactive rebase you should now see something like this.

You see the list of commands below the commits!? Quite a lot of things you can do. From editing commit messages over squash merging to executing bash commands (!!).

We simply want to remove the top two commits though. That's pretty easy by replacing the pick at the beginning of the lines with drop or d. It's even easier to just remove the lines altogether (which is mentioned in the second last line).

I simply remove the lines with the top two commits that belonged to the content-container branch.

Now save and exit the editor. You can just overwrite the existing file if you're asked.

This is what you should see.

Great! Everything seems to have worked fine.

Double-check

Let's quickly verify that the commit history looks as expected. Run the git log command on the bottom-section branch. This is how my output looks like.

This looks as expected. Only one commit is left on the bottom-section branch.

Finally, let's have a quick look at the file src/styles.css to see if the .content and .section classes are still correct.

.content {
  min-height: calc(100vh - 100px);
  width: 720px;
  max-width: 100%;
  margin: auto;
}
 
.section {
  height: 450px;
  width: 100%;
  margin-top: 20px;
  display: flex;
  justify-content: center;
  align-items: center;
  border: 1px solid black;
}

For me, everything is still in place. Hopefully for you too.

Force push

The last step on the roadmap is again to force push our changes to update the remote repository.

Once you pushed you can check the file changes in the Bottom Section PR on GitHub. Inside the styles, you should only see changes in the .section class and not the .content class as before.

Recap

Great job! You learned about the awesome interactive rebase command and used it in practice. Seems like we're done for now.

Could you help me out?

If you enjoy this course so far I'd be super grateful if you could share it with your friends.

Spread the word