Previous Tip: Commit Message Conventions

Continuing the Git series, in this post I’ll cover why rebasing over merging can make a huge difference, and why is our preferred way.

What is the difference between merge and rebase?

Being extremely succinct, Merge and Rebase are two different ways of adding code from one branch to another, the main difference is how the history will be written after the code is integrated in the target branch as well as how much control you have when joining two branches. Please consider reading the Atlassian tutorial it explains both methods with clear graphics.

Workflow

git rebase is used when working on feature branches to always be on top of the all changes that the original branch currently has and any future changes to be pushed by other team members.

The following will be a common workflow:

git checkout master
git checkout -b fix/TKT-100-fix-things
# ... stuff happens and we use the well knonwn "commit" "push" 
git rebase master # we always keep our branch up to date

Then after our feature branch is reviewed and ready to be joined into master, we do something like this:

git checkout master
git rebase fix/TKT-100-fix-things

In cases where we are deploying something into a release branch, we use merge instead:

git checkout production
git merge master

That way we can a commit message to indicate some possible changes that indicate what happened during this release.

The idea of using rebase instead of merge when joining branches allows us to have a clean an concise Git history, and to avoid messes like this:

Back to posts