Context in this post: You have a base branch master and you start working on a new feature in a dedicated branch. Then another team member updates the master branch with new commits and you need to integrate these new commits into your feature branch.
You will have 2 options to integrate new commits on masterbranch into your featurebranch. Git Merge and Git Rebase.
The Merge Option
The easiest option is to merge the master branch into the feature branch using something like the following:
git checkout feature
git merge masterOr, you can condense this to a one-liner:
git merge feature masterThis creates a new “merge commit” in the feature branch that ties together the histories of both branches, giving you a branch structure that looks like this:
Merging is nice because it’s a non-destructive operation. The existing branches are not changed in any way. This avoids all of the potential pitfalls of rebasing (discussed below).
On the other hand, this also means that the feature branch will have an extraneous merge commit every time you need to incorporate upstream changes. If master is very active, this can pollute your feature branch’s history quite a bit. While it’s possible to mitigate this issue with advanced git log options, it can make it hard for other developers to understand the history of the project.
The Rebase Option
As an alternative to merging, you can rebase the feature branch onto master branch using the following commands:
git checkout feature
git rebase masterThis moves the entire feature branch to begin on the top of the master branch, effectively incorporating all of the new commits in master. But, instead of using a merge commit, rebasing re-writes the project history by creating brand new commits for each commit in the original branch.
The major benefit of rebasing is that you get a much cleaner project history. First, it eliminates the unnecessary merge commits required by git merge. Second, as you can see in the above diagram, rebasing also results in a perfectly linear project history—you can follow the top of feature all the way to the beginning of the project without any forks. This makes it easier to navigate your project with commands like git log, git bisect, and gitk.
But, there are two trade-offs for this pristine commit history: safety and traceability. If you don’t follow the Golden Rule of Rebasing, re-writing project history can be potentially catastrophic for your collaboration workflow. And, less importantly, rebasing loses the context provided by a merge commit—you can’t see when upstream changes were incorporated into the feature.
The Golden Rule of Rebasing
Once you understand what rebasing is, the most important thing to learn is when not to do it. The golden rule of git rebase is to never use it on public branches.
For example, think about what would happen if you rebased master onto your feature branch:
The rebase moves all of the commits in master onto the tip of feature. The problem is that this only happened in your repository. All of the other developers are still working with the original master. Since rebasing results in brand new commits, Git will think that your master branch’s history has diverged from everybody else’s.
The only way to synchronize the two master branches is to merge them back together, resulting in an extra merge commit and two sets of commits that contain the same changes (the original ones, and the ones from your rebased branch). Needless to say, this is a very confusing situation.
So, before you run git rebase, always ask yourself, “Is anyone else looking at this branch?” If the answer is yes, take your hands off the keyboard and start thinking about a non-destructive way to make your changes (e.g., the git revert command). Otherwise, you’re safe to re-write history as much as you like.
Force-Pushing
If you try to push the rebased master branch back to a remote repository, Git will prevent you from doing so because it conflicts with the remote master branch. But, you can force the push to go through by passing the --force flag, like so:
# Be very careful with this command!
git push --forceThis overwrites the remote master branch to match the rebased one from your repository and makes things very confusing for the rest of your team. So, be very careful to use this command only when you know exactly what you’re doing.
One of the only times you should be force-pushing is when you’ve performed a local cleanup after you’ve pushed a private feature branch to a remote repository (e.g., for backup purposes). This is like saying, “Oops, I didn’t really want to push that original version of the feature branch. Take the current one instead.” Again, it’s important that nobody is working off of the commits from the original version of the feature branch.
Reviewing a Feature With a Pull Request
If you use pull requests as part of your code review process, you need to avoid using git rebase after creating the pull request. As soon as you make the pull request, other developers will be looking at your commits, which means that it’s a public branch. Re-writing its history will make it impossible for Git and your teammates to track any follow-up commits added to the feature.
Any changes from other developers need to be incorporated with git merge instead of git rebase.
For this reason, it’s usually a good idea to clean up your code with an interactive rebase before submitting your pull request.
Integrating an Approved Feature
After a feature has been approved by your team, you also have the option of rebasing the feature onto the top of the master branch before using git merge to integrate the feature into the main code base.
This is a similar situation to incorporating upstream changes into a feature branch, but since you’re not allowed to re-write commits in the master branch, you have to eventually use git merge to integrate the feature. However, by performing a rebase before the merge, you’re assured that the merge will be fast-forwarded, resulting in a perfectly linear history. This also gives you the chance to squash any follow-up commits added during a pull request.
If you’re not entirely comfortable with git rebase, you can always perform the rebase in a temporary branch. That way, if you accidentally mess up your feature’s history, you can check out the original branch and try again. For example:
git checkout feature
git checkout -b temporary-branch
git rebase -i master
# [Clean up the history]
git checkout master
git merge temporary-branchSummary
And that’s all you really need to know to start rebasing your branches. If you would prefer a clean, linear history free of unnecessary merge commits, you should reach for git rebase instead of git merge when integrating changes from another branch.
On the other hand, if you want to preserve the complete history of your project and avoid the risk of re-writing public commits, you can stick with git merge. Either option is perfectly valid, but at least now you have the option of leveraging the benefits of git rebase.
QE notes:
Git merge generates extraneous merge commit.
After rebase, you have to add -force to push it to remote because Rebase rewtires the history of all commits in your branch.
If you already have one or more merge master commits, When you want to merge the pull request (Github) to master branch , consider using Rebase and merge option instead of Create a merge commit (default). Rebase process will remove all merge commits before merge into master.
If your commit 3 is just a correction or update for commit 2 , or if your all commits should be in just one commit, make use of git rebase -i to squash the commits into one commit. it is also easier for reviewer to review your code.
As a pitfall of rebasing, it moves your all commits on top of master then rebase one by one, So you may see a code conflict in rebase commit 1 but this code actually will be removed in commit 10 and you feel it is tedious to rebase all your commit , This is when you use git merge.
Remember , If you rebase your branch with master, the rebase process only rewrites history of your branch commits, it doesn’t touch master commits. When you merge your branch to master, commits of your branch will be on top of master.
If you use git merge to integrate new commits on master into your branch, a new merge commit will be added into both your branch as well as master branch. It makes hard to understand when people look at git log.
Reference Links:
Step Up Automation 