我使用git近2年了，现在我很困惑是要重新绑定分支还是将分支与master合并。
我搜索了这个网站，没有发现任何与我的具体原因/论点相关的问题。
我个人从不鼓励任何人改变分支机构。我总是坚持大家将分支合并到主人。当然，在一些我们没有其他方式的特殊情况下，除了变基或创建新的分支外，我选择了变基。
我之所以没有鼓励并且主张不去反驳的原因是，让我们说两位开发人员正在两个不同的分支机构工作。
不幸的是，开发人员引入了一个错误，他的代码失败了。现在开发人员2也有这些变化。
除非开发人员解决了这个问题，否则开发人员不能继续。然后开发人员必须再次修改以获得修复。
此外，如果开发人员1和开发人员2正在处理两个不同的功能，如果我们修改开发人员的两个分支或反之亦然，则两个分支都将包含这两个功能。除了提交的数量也会增加。
让我们说开发者已经为他的功能做了三次提交。在开发人员两次rebase后，他将提交他的功能加上开发人员的提交。哪个会提交更多提交。
另一方面，如果开发人员必须始终为master上的每个合并进行rebase，那么拥有分支的重点是什么？开发人员2可以执行以下操作。
这样至少开发人员2不需要总是变基。
在一天结束时，在开发人员2将他的代码与master合并之后，开发人员二的分支和master是等效的。从技术上讲，有两个不同名字的大师。
这就是我所争论的。
但是，我鼓励rebase仅在开发人员2已经扩展并且几天之后基本代码在master上进行了大量修改，其中开发人员2工作的大部分功能已经改变。然后我认为可以改变并修复所有冲突并开始继续。
实际上我们遵循敏捷。据我所知，理想情况下，在敏捷中，同一个sprint中的两个用户故事不会使用相同的功能/代码。因此，如果我们总是选择合并代码而不是重新定位，那么合并冲突最小或没有。
最后，我想知道开发人员是否必须在没有任何理由的情况下始终与master进行rebase，或者没有拇指规则必须始终进行rebase。
变基和合并的利弊是什么？
提前谢谢大家。如果我问一个愚蠢/毫无意义的问题，我很抱歉。
答案 0 :(得分：0)
合并
重新基础
在不创建新提交的情况下，将一个分支的更改重写到另一个分支。
代码历史记录简化，线性且易读。
重新定位不适用于拉取请求，因为您无法看到有人做出的微小更改。
处理冲突时需要更多工作。使用rebase更新功能分支需要您反复解决类似的冲突。
希望这可以帮助您解决对这两个命令的疑虑。我在this article中找到了此信息，请务必查看详细信息。