git 合并与变基 [英] git merge vs rebasing

问题描述

我使用 git 已经快 2 年了，现在我很困惑是重新设置分支还是将分支与 master 合并.

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.

我个人从不鼓励任何人重新设置分支.我一直坚持大家把分支合并到master.当然，在某些特殊情况下，除了变基或创建新分支之外，我们别无他法，我选择了变基.

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.

我从不鼓励和争论不要 rebase 的原因是，假设两个开发人员在两个不同的分支上工作.

The reason why I never encouraged and argued not to rebase is, lets say two developers are working on two different branches.

1. 开发人员一两个结帐到新的分行.
2. 开发者一提交了一些代码并与大师合并.
3. 开发人员 2 有一些本地更改.然后，他使用 master 对分支进行 rebase，然后应用他的更改并提交，然后与 master 合并.

不幸的是，开发人员引入了一个错误并且他的代码失败了.现在开发者二也有这些变化.

Unfortunately developer one has introduced a bug and his code failed. Now developer two also has these changes.

除非开发人员一解决问题，否则开发人员二无法继续.然后开发人员 2 必须再次变基以获得修复.

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.

另一方面，如果两个开发人员必须始终为 master 上的每次合并重新设置基础，那么拥有分支的意义何在?开发人员二可以执行以下操作.

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.

1. 他将为大师工作.
2. 当他决定推送代码时，他会隐藏更改.
3. 提取最新更改.
4. 将扩展到一个新的分支.
5. 然后弹出更改
6. 修复合并冲突(如果有)
7. 创建一个提交，然后与 master 合并.

这样至少开发人员二不需要总是变基.

This way atleast developer two need not always rebase.

归根结底，开发者二将自己的代码与master合并后，开发者二的分支和master是等价的.从技术上讲，有两个名称不同的大师.

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.

这就是我所争论的.

然而，我鼓励只有在开发人员二已经分支并且几天后基本代码在 master 上进行了大量修改时才鼓励 rebase，其中开发人员二正在工作的大部分功能都发生了变化.然后我认为可以重新设置并修复所有冲突并开始继续.

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.

最后，我想知道开发人员是否必须毫无理由地始终使用 master 进行变基，或者是否没有必须始终变基的经验法则.

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.

推荐答案

合并

• 与 Rebase 相比更易于使用和理解.
• HEAD 分支将生成一个新的提交，保留每个提交历史的祖先.
• 提交历史可能会受到大量合并提交的污染，因为多人同时在同一个分支上工作.

重新定位

• 将一个分支的更改重写到另一个分支上，而无需创建新的提交.

• 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.

在处理冲突时需要更多的工作.使用 rebase 来保持你的功能分支更新需要你一次又一次地解决类似的冲突.

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.

希望这能帮助您解决有关这两个命令的一些疑问.我在这篇文章中找到了这些信息，请务必查看以获取更多详细信息.

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.

这篇关于git 合并与变基的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！