Simplify - How to Use Git Merge and Git Rebase Appropriately?

Problem

After finishing a feature, we merge it into develop. The git merge command basically combines changes from one branch to another and can create an additional commit to mark the merge.

Recently, you have also heard about the git rebase command. Through research, you have found that it is also used to merge changes from one branch to another. The only difference is how git merge and git rebase create commit history.

However, you may have heard advice that if you are new, don't rush to use git rebase. While git merge is solving your problems well, continue using it. Honestly, I am not certain about using git rebase either, but I have a small tip that I would like to share with you in this article, hoping it will be helpful.

A Common Scenario

In practice, many projects have two basic branches: master and develop. The code in master is put into production while the code in develop runs in the development environment. (In reality, there may be more branches and it can be more complex, but I'm only using a basic example).

To develop a new feature, I check out from develop into a new branch and then start development on it. Branches can follow the rule feature/01, feature/02... with 01, 02... being the names of the features.

During development, there may be multiple features being developed concurrently and independently. What if you need changes from feature/01 to be incorporated into feature/02? Merge feature/01 into feature/02? Not bad! But if you continue doing that, your commit history may become messy. Instead, why not try this approach?

Principle: Always let develop serve as the intermediate branch between feature branches because ultimately the features have to be merged into develop. So, if you need changes from feature/01 into feature/02, merge feature/01 into develop, and then rebase feature/02 onto develop.

If you merge feature/01 directly into feature/02, the commit history will look like this:

Doesn't the git tree look more complex compared to the initial state?

The Golden Rule of Rebase

The golden rule of rebase is clearly stated in the article Merging vs. Rebasing. I will summarize it: never use rebase on a shared branch. In the above example, the shared branch is develop. Why? If we rebase feature/01 or feature/02 onto develop, the commit history on develop will be "rewritten".

As shown above, when we rebase feature/01 onto develop (Main in the image), the new commits of develop are added after the latest commit of feature. At this point, the develop branch has a "rewritten" commit history. Just imagine if multiple people are working based on develop from prior to this point. Performing merge operations in the future will cause many confusing issues.

Conclusion

In summary, merge is always sufficient. You don't need to know about rebase, and it's okay. But if you want to have a cleaner git commit history, you can try rebase. The golden rule is to never rebase a feature onto develop (never rebase on a shared branch). Only rebase feature onto develop, and vice versa, merge develop into feature.

References:

• Merging vs. Rebasing
• When do you use git rebase instead of git merge?