Lesson Git Merge and Git rebase compare
git rebase This command has often been considered a Git witchcraft, beginners should stay away. However, if used properly, it can give your team develop eliminating too much trouble. In this article, we will compare git rebaseand similar git mergecommand, use rebase to find all of Git workflow.
Outline
The first thing you should know is that git rebase , and do in fact is the same. They are designed to be a change branch merged into another branch, but their implementation is somewhat different.git merge
Imagine you've just created a special branch to develop new features, and then another member of the team added a new commit on the master branch. This will cause the submission history is bifurcated (Fork) a, for developers using Git to collaborate for such a situation should be very common.
Now, if the new submission master in your job function and development are related. In order to incorporate the new submit your branch, you have two options: merge or rebase.
Merge Options
The master branch into feature branch easiest way is to use the following commands:
git checkout feature
git merge masterAlternatively, you can put them in a row Yajian:
git merge master featureThis will create a new merge commit (function (feature) branches merge commit) will link the two branches of history together. You'll get a branching structure below:
Merge Fortunately, it is a safe operation. Existing branches will not be changed to avoid a rebase potential drawback (later would say).
On the other hand, this also means that each branch will merge upstream changes introduced merge feature an unrelated submit. If the master is very active, then it will pollute more or less the history of your branch. Although the advanced git logoptions can alleviate this problem, but for developers, or will increase the difficulty of understanding the history of the project.
Rebase option
As an alternative merge, you may like this feature branch into the master branch:
git checkout feature
git rebase masterIt will effectively put a new branch of incorporation filed over all master, and move the entire feature branch back to the master branch. However, rebase will rewrite the history of the project, it will not bring merge commit, but creates a new submission for each submission on the original branch.
The biggest advantage is that you rebase commit history of the project will be very clean. First of all, it is not git as introducing unnecessary merger submit merge. Secondly, as shown above, rebase leading to the final project history showing perfectly linear - you can project from the start to the end of the browser without any bifurcation. This makes it easier to use git log , git bisect and gitk to view the history of the project.
However, this simple commit history will bring two issues: security and traceability. If you violate Rebase golden rule , to rewrite the history of the project may give your development workflow devastating impact. In addition, rebase operation does not increase its combined back - so you can not see what time to come together upstream branch feature branch.
Interactive rebase
Interactive rebase allows you to change into the new branch of submission. This is more powerful than the automatic rebase, because it provides complete control over your history on the branch. In general, this feature is used to branch into the master branch prior to clean up the mess history.
The -i option to git rebase incoming begin an interactive rebase process:
git checkout feature
git rebase -i masterIt will open a text editor, shows all submissions will be moved:
pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3 This list defines the rebase will be executed after the branch would be like. Change the pick order or reorder this branch of history can be changed according to your ideas. For example, if the second submitted fixes minor problems first submission, you can use the fixup command to put them together into a submission:
pick 33d5b7a Message for commit #1
fixup 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3
Save and close the file, Git rebase will be executed according to your instructions, the history of the project will look like this:
Ignore minor historical feature will let you submit branches more legible. This is impossible.git merge
Rebase the golden rule
When you understand what rebase Yes, the most important thing is when not to use rebase. git rebase The golden rule: never use it on a common branch.
For example, if you rebase the master branch to branch on your feature what happens:
This will be submitted to rebase all moved back feature branch master all the branches. The problem is that it only happens in your code repository, all other developers are still working on the original master. Because rebase caused a new submission, Git will think your master's master branch and others have diverged.
The only way to synchronize the two master branches are to merge them together, resulting in an extra merge commit and submit piles contain the same changes. Needless to say, this will make people very confused.
So, before you run git rebase, be sure to ask yourself, "Is there someone else is working on this branch?." If the answer is yes, then put your claws back, to rediscover a sound manner (such as git revert) to submit your changes. Otherwise, you may want to rewrite history.
Forced Push
If you want to master branch after rebase pushed to the remote repository, Git will stop you from doing so, because the two branches contain conflict. But you can pass -force flag to force push. Just like the following:
# 小心使用这个命令！
git push --force It will rewrite the master remote to match the master branch after branch of your warehouse rebase, for the other members of the team for this looks very strange. So, be careful this command only when you know what you are doing when re-use.
Use one of the few scenes that forced a push, when you want to push a private branch to the remote repository, perform a local clean-up (for example, rolled back). It's like saying, "Oh that feature branch before, in fact, I do not want to push. I replaced it with the current version." Also, you should note that no one else is working on a feature branch.
Applied to the development workflow
rebase can apply more or less in Git workflow of your team. In this section, we take a look at the various stages of the development of feature branch, rebase What are the benefits.
In the workflow balancing git rebase the negative effects of the first step is to create a functional development of the special feature branch. This allows branch structure you have the safe use of rebase:
Local clean-up
Use one of the best usage rebase in your workflow is being developed to clean up a local branch. From time to time perform an interactive rebase, you can ensure that your feature branch each submission is specific and meaningful. When you write code without worrying about causing loose submit - you can use rebase to solve this problem.
Call git rebase time, you have two options to go to be considered: the upstream branch (such as master) or your feature branch in a previous submission. We in the "interactive rebase" one saw the first example. In the latter when you only need to change a few times when the latest submission is also useful. For example, the following command in the latest three submitted an interactive rebase:
git checkout feature
git rebase -i HEAD~3 通过指定HEAD~3作为新的基提交，你实际上没有移动分支——你只是将之后的3次提交重写了。注意它不会把上游分支的更改并入到feature分支中。 If you want to use this method to rewrite the entire feature branch, git Merge-Base command is very easy to find the base feature forked branch began. This command returns the following ID-based submission, you can pass it to the next git rebase:
git merge-base feature masterThe interactive rebase git rebase the introduction of in your workflow in a good way, because it only affects the local branch. Other developers can only see the results that you have done, and that is a very clean and easy to track the branch history.
But again, this can be used on a private branch. If you cooperate with a feature branch and other developers, then this branch is open, you can not rewrite the history.
Submitted by local clean-up with interactive rebase, it is impossible to use git Merge command instead of.
The change in the upstream branch into the branch feature
In an overview, we see the feature git branch how to incorporate upstream branch merge or git rebase. merge safe choice is to retain your complete history, rebase your feature branch will move to the back of the master branch, create a linear history.
git rebase usage and local clean-up is very similar to (and can be used simultaneously), but incorporates upstream changes on the master between.
Remember, rebase to the remote branch rather than master also perfectly legal. When you and another developer on the same feature points of collaboration, you will use this usage, their changes incorporated into your project.
For example, if you and another developer --John-- on feature to add a few branches of submission, after John fetch from the repository, your repository might look something like this:
On the upstream and incorporate the same changes on the master, so you can solve this Fork: either merge your local branch and branches John's, or your local branch to rebase branch behind John's.
Note, rebase Rebase here did not violate the golden rule, because only commit on your local branch was moved, before all things have not changed. It's like saying "my changes applied to the back of John's go." In most cases, this submission to synchronize the remote branch is more intuitive than through mergers.
By default, git pull command performs a merge, but you can pass -rebase to force it to integrate remote branch through rebase.
Review with Pull Request
If you pull request as part of your code review process, you need to avoid using git rebase After you create pull request. As long as you initiate a pull request, other developers can see your code, which means that this branch into a common branch. Git will result in rewriting history and your colleagues find this difficult branch of any subsequent submission.
Any changes from other developers should use git to incorporate merge instead of git rebase.
Therefore, using interactive rebase pull request before submitting code cleanup is usually a good idea.
Incorporated by branching function
If a function is passed your team, you can branch after rebase the master branch to select, or use git Merge to this function into the main code base.
This change will be incorporated into the upstream branch feature is very similar, but you can not rewrite submitted in the master branch, you will eventually need to use git Merge to incorporate this feature. However, before you perform a merge rebase, you can ensure that the merge is straight ahead, and finally generated is a completely linear commit history. This way you can also add submitted after the pull request.
If you are not completely familiar with git rebase, you can also perform rebase in a temporary branch. In this case, if you accidentally mess up the history of your feature branch, you can also view the original branch and try again.
For example:
git checkout feature
git checkout -b temporary-branch
git rebase -i master
# [清理目录]
git checkout master
git merge temporary-branchto sum up
You need to know before you use rebase the knowledge points in this. If you want a clean, linear project history, no unnecessary merge commit, you should use git rebase instead of git Merge to incorporate changes on other branches.
On the other hand, if you want to save the complete history of the project, and avoid rewriting commit on a common branch, you can use git Merge. Both options are very easy to use, but at least you now have the choice git rebase.
Original Source