Git Rebasing - 14 days of Git

It is Day 11 of my learning journey into Git.  So far on my learning journey has taken me on the following path:

• What is version control?
• What is Git?
• Installing Git
• Basic Git commands to get started
• Inspect a Git repository
• Git File Operations
• Undoing commits and changes
• Rewriting history
• Git Branches
• Merging with Git

Are you joining me on this learning journey? Would love to hear how you are doing.

Today's learning objective is around Git rebasing, what it is and why you would use it.

What is Git Rebasing?

Rebasing your Git repository rewrites its history.  It can be a harmful command, so it is one to watch when you use it.

Typically, you would use the git rebase command for one of the following reasons:

• Edit a previous commit message
• Combine multiple commits into one
• Delete or revert commits that are no longer necessary

Why do we need Git rebase?

Rebasing rewrites the project's history.  It gives you a much cleaner project history. Rebasing eliminates the unnecessary merge commits required by git merge.  It gives a much linear history when you are looking back at your logs.

Rebase a Git repository

We have a repository with the main branch and then a feature branch. We've been working away on different things on this feature branch and have several commits.  If we look at the graph of this, it will look something along the lines of this.

We want to bring all the commits and cool new features we've been creating from our feature branch into our main branch.  But we want to make the history as linear as possible. So instead of doing a git merge we are going to use git rebase.

The commands we want to use are:

git checkout main
git rebase featurebranch

The first command makes sure we are in our main branch and the second command rebases that main branch to include the commits from feature.

Our git graph log would look like this:

You can see our history has been rebased into the main branch in a linear way.

If we'd used the git merge command instead this is what our repository history would look like:

Using the git rebase command gives you a much clearer history, especially if you have a large team of developers working on different features and bugs.  It can become a real message if you are only using git merge.  The history really becomes hard to read and understand.

Git rebase isn't always the right option though, as it does rewrite history.  It's important as a team you understand the right use case for git rebase over git merge and use it appropriately.

14 days of Git

I'll be honest, this one took a little time to understand and really appreciate what it was for.  I still think there is more I can dig into on this one. Definitely booking marking this one so I can come back to it and do some more learning.

Tomorrow is all about stashing so that should be interesting! Be sure to subscribe and join me for that step in the learning journey!

You can follow along here: https://github.com/weeyin83/14daysofgit