问题
I am using git from almost 2 years and now I am confused whether to rebase a branch or merge the branch with master.
I have searched this site and did not find any question related to my specific reasons/argument.
I personally never encouraged anyone to rebase a branch. I always insisted everyone to merge the branch to master. Off course in some special cases where we had no other ways, except rebasing or creating a new branch, I opted for rebasing.
The reason why I never encouraged and argued not to rebase is, lets say two developers are working on two different branches.
- Developer one & two checked out to new branches.
- Developer one committed some code and merged with master.
- Developer two has some local changes. He then rebases the branch with master and then applies his changes and commits and then merges with master.
Unfortunately developer one has introduced a bug and his code failed. Now developer two also has these changes.
Developer two cant continue unless developer one addresses the issue. Then developer two has to again rebase to get the fix.
Besides, if developer one and developer two are working on two different features, if we rebase developer's two branch or vise versa, both branches will contain both features. Besides the number of commits also will increase.
Lets say developer one has made three commits for his feature. After developer two rebases he will have commits of his feature plus developer one's commits. Which will make more commits.
On the other side, if developer two has to always rebase for every merge on master then what is the point of having a branch? Developer two can do the following.
- He will work on master.
- When he decides to push the code, he will stash the changes.
- Pull the latest changes.
- Will branch out to a new branch.
- Then pop the changes
- Fixes merge conflicts if any
- Create a commit and then merge with master.
This way atleast developer two need not always rebase.
At the end of the day, after developer two merges his code with master, developer two's branch and master is equivalent. Technically there are two masters with different names.
This is what I argue about.
However I encourage rebase only if developer two has branched out and after few days the base code is modified a lot on master, where most of the functionality on which developer two is working has changed. Then I think its okay to rebase and fix all conflicts and start going ahead.
Actually we follow agile. As far as I know, ideally in agile there wont be two user stories in the same sprint working on the same functionality/code. So there will be minimum or no merge conflicts if we always opt for merging the code instead of rebasing.
Finally I want to know whether a developer has to always rebase with master without any reason or is there no thumb rule one has to always rebase.
What are the pros and cons of rebasing and merging?
Thank you all in advance. And I am sorry if I ask a silly/pointless question.
回答1:
Merge
- Simpler to use and understand compared to Rebase.
- HEAD branch will generated a new commit, preserving the ancestry of each commit history.
- Commit History can become polluted by lots of merge commits because multiple people are working on the same branch in parallel.
Rebase
Re-writes the changes of one branch onto another without creating a new commit.
Code history is simplified, linear and readable.
Rebasing doesn't work with pull requests, because you can't see what minor changes someone made.
It requires more work when dealing with conflicts. Using rebase to keep your feature branch updated requires that you resolve similar conflicts again and again.
- You need to be more careful with rebasing than when merging because of the above statements.
Hope this will help you to resolve some of your doubts of when it comes to those two commands. I found this information in this article, be sure to check it out for more details.
来源：https://stackoverflow.com/questions/24367360/git-merge-vs-rebasing