Git Branching and Merge vs Rebase
Git branching strategies are used very often when dealing with distributed version control system. Let’s take a sneak peek as to why branching is essential when developing a software collaboratively. Version control systems like Git are intended to provide more comfort to software developers and QA engineers by allowing them to compare files, differentiate between them and merge any changes between the files if necessary. To make this all happen branching is very much needed. Here is why,
- Git branches are inexpensive to create and maintain.
- Making feature branches makes reviewing history simpler.
- Can add more information like developer name when naming the branch which will later be helpful.
- Maintaining feature branches renders a separate workspace to every change and bug-fixing.
There are three basic concepts to follow when branching.
- Create a feature branch every time you add a new change or do a bug fixing.
- After comparing and approving differences you made, you can merge feature branches into the master branch.
- Maintaining the master branch clean and up to date with all the changes.
Moreover, you can use a visual diff tool like P4Merge to easily trace any changes you make while you are branched by visually comparing the changes you made in the feature branch with the master branch.
Git Merge
Now that branching has been taken care of, the next very important thing is Merging. Merging is really helpful and more rewarding if you use a visual diff tool because it’s very easy to solve any conflicts created in the process. By using “git merge”, we can place all the changes we made in the feature branch to the master branch as if we never branched away. To do a simple merge we can use the following command:
- You can checkout to the master branch using “
git checkout master” - Then merge the feature branch into the current branch(master) using “
git merge <name of the feature branch>”
Basically, there are two types of merges.
1) Fast forward merge
Let’s have a look under the hood at Fast Forward merge in this section. This way of merging is only possible when there is a beeline path from current branch to the master branch. This is the most popular way of merging which involves three steps,
- Branching away into some feature branch
- Adding new changes on the feature branch created.
- Merging changes back to the master branch.
Note that, we do not make any commits on the master branch which leads to diverging (beeline). We branch away, make/add changes and then simply merge it back to the master branch which does not contain any contradicting changes.
Following is a small example and commands to illustrate this scenario.
2) 3-Way merge
Before going into further details it’s important to grasp the reason as to why we need 3-Way Merge. Imagine you’re working on a group project where multiple developers contribute to the master branch. In this scenario, you can’t merge the changes you made, into the master branch in fast forward, because it is not up to date with the branch you’re working on. This is basically because you’re not the only person contributing to the master branch. So, there’s no way of merging without backtracking changes on the master branch. In times like these, 3-way merge is a good approach to take now that doing a fast forward merge is impossible.
If your branch is as small as the above example, then we can rebase it into master branch and do a fast forward merge. But most of the time, it’s not practical because these changes on feature branches are large and consume a lot of developing time.
Let’s clear all the doubts with an example,
If the two branches we want to merge have different versions of the same file (file changed independently), Git gets confused not knowing which change it should use to proceed. This arouses a conflict. When you’re confronted with a conflict you can execute a “git status” command and it will present you the parties involved in the conflict. This is really useful when dealing with a big project which has so many branches.
Merge command will lead into a conflict as predicted.
As I stated above configuring a visual merging tool to work along with git makes these situations much easier to handle. So, once you identify the conflicting areas and decide on what you want to proceed with, you can leave only the changes you want with the P4 merge, and then perform a “git commit”.
Now that we have a basic idea about how merging works, Let’s catch a glimpse of the basics and pitfalls of rebasing.
Git Rebase
Let’s dig into this with an example. Suppose the master branch has many more updates than the feature branch you’re working on because other members of the project added changes to the master branch. Now you want to update your feature branch with the upstream changes in the master branch. But you obviously don’t want your branch history to get messed up with all the irrelevant commits. You want to maintain the clean slate of the history of your branch because there’s no guarantee about the master branch being bug free. Also, it’s easy to reason all the commits with “git log”.
Now you’re left with two options for the integration,
- Merging directly.
- Rebasing and Merging.
Merging directly will lead you to a 3-way merge and it’s not always the best practice when working on large projects. Choosing the second option is comparatively chaos free because it makes fast forward merge possible. In other words, you can move the base of the feature branch to the master branch ending point by rewriting history. There are times where doing a rebase is not accepted. Particularly if the feature branch you’re working on is public.
Merge vs Rebase
Now it’s time to compare git Merge and Rebase. Let’s have a quick glance at the differences and similarities.
One of the main similarities between these two is their objective/target which is combining two branches together. But they have their own way of achieving this common target. Merge command adds your changes with a commit without making any changes to the history whereas rebase is known to apply feature branch changes on top of the master branch and thus rewrites the history.
Also, git merge is simple and takes less time to master. On the other hand Rebase involves a lot of practice and knowledge about git concepts as well as the project domain.
Another difference between Merge and Rebase comes to play when we try to apply them. Git merge can be used despite whether the feature branch is private or public. But git Rebase can’t be used when the branch is public, and many developers work on it without impacting them. So, it’s best to use Rebase privately.
As mentioned above, git Merge preserves history while Rebase rewrites it. So, there can be occasions where maintaining a complete and unbiased history is important. So, in those situations going for Merging is a good choice if you have a linear connection between concerned branches.
References:
