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.
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.
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
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: