当我是唯一一个在两个相关分支上工作时，我应该使用git rebase而不是git merge

Question

假设rebase涉及两个分支A和B 我是唯一一个对这些分支机构进行更改的人，但还有其他人只是为了查看正在发生的事情（审查）而取消了这些分支机构。 他们根本没有对这些分支进行任何修改。 考虑到rebase vs merge的优缺点，变基显然是更好的选择

现在，关于rebase的git文档提到了关于变基的黄金法则

git rebase的黄金法则是永远不要在公共分支上使用它。

并解释为什么它可能是危险的。

我理解rebase和merge之间的区别以及当其他开发人员提交到父分支时情况会出现问题。

即使我是那两个关于变基的分支机构的唯一开发人员，我是否应该避免这种情况？ 在重新定位之后强行推动并且其他团队成员试图拉动那些分支（再次只是为了查看它们，他们没有做出任何改变）之后会出现什么问题？

Answer 1

要确定是使用rebase还是合并，首先需要了解它们的工作原理。

在git中， 提交是链表的链，后面的提交引用了先前的提交。

C1<-C2<-C3<-C4

当两个分支合并时， 创建一个新的合并提交 （由下面的M1表示）

C1<-C2<-C3
 \        \
  \       M1
   \      /
   C4<-C5

其中包含正在合并的提交的引用。 历史不再是一个链表 。 它已成为有向无环图。

Rebase以不同的方式工作

C1<-C2<-C3 branch1
  \  
       C4<-C5 branch2

#On branch2
git rebase branch1

  C1<-C2<-C3<-C4'<-C5'

Rebase 创建了两个新的提交C4'和C5'而不是C4和C5，并将分支指针移动到C5'。 这里的历史记录是干净的链表 （因为你的分支提交被重新创建并应用到完成了rebase的分支），但是创建了两个新的提交，意味着为branch2更改了历史 （之前是C1 <-C4 <-C5）。 因此，每次进行变形时都必须强制推动。

现在回答你的问题：

1. 即使我是那两个关于变基的分支机构的唯一开发人员，我是否应该避免这种情况？ 在最佳实践中，最好使用父分支重新定义您的功能分支，然后将您的功能分支合并到父分支 ，因为功能分支是您自己的分支，但父分支也会有其他开发人员提交，如果您重新设置，这可能会丢失你的父分支与功能分支没有从远程拉。

2. 在重新定位之后强行推动并且其他团队成员试图拉动那些不同的东西后，可能会出现什么问题？ 随着强制推动它会变得非常糟糕， 将您在本地系统上的任何历史记录推送到远程 。 如果你不使用强制推送，那么你的推送将被拒绝，因为历史不匹配并提交转换，你将被要求采取拉动。 此外，如果您在父分支上强制推送其他开发人员提交并且未在本地计算机上提取，则该提交将丢失。

如果其他开发人员试图从远程进行拉取，他将会遇到树冲突，因为他的本地历史记录不会远程使用。

Answer 2

当审阅者提取您的代码时，可能会出现问题。

Git将获取重新提交的提交并尝试将其与审阅者的分支合并。

这将创建一个合并提交 - 如果一切顺利或将导致合并冲突。

因为git无法知道新提交是重新设置还是完全不同，所以它将保留旧的pre-rebase提交并将其与post-rebase提交合并。 在任何一种情况下，即使代码相同，其机器上的提交历史也将始终与您的不同。

Answer 3

关于变基的“黄金法则”有一个扩展版本：

git rebase的黄金法则是永远不要在公共分支上使用它。

扩展版本如下所示： 仅对分支名称使用rebase或其他强制推送类型的运动，其中该名称的所有用户都期望产生的行为 。 这是因为每个这样的用户可能必须采取一些动作来从这种操作中恢复（“上游变基”）：即，他或她可能必须“拯救”他或她的提交。 如果所有用户都准备这样做，并且知道寻找这样的情况，他们就不会对这个问题感到惊讶。

换句话说，如果你有一个团队，比如五个程序员，并且你们五个人都同意“pu”（“建议的更新”或“拾取”分支）一直被重新定位，那么改变pu是没关系的。科。 如果你们中的一个是与基础重建“发展”，但四个是也不行，它不是确定以变基的“开发”分支。

由于您是唯一使用A和B的用户和开发人员，因此由您自行决定是否同意自己是否可以重新定义A和/或B.

Answer 4

在重新定位之后强行推动并且其他团队成员试图拉动那些分支（再次只是为了查看它们，他们没有做出任何改变）之后会出现什么问题？

没有什么能真正“出错”。 可能发生的最糟糕的事情是“观察者”在合并时会遇到不必要的麻烦，因为你们新推出的强制提交可能看起来完全不同，现在拉动（即获取和合并）它们会导致合并冲突 。

即使我是那两个关于变基的分支机构的唯一开发人员，我是否应该避免这种情况？

虽然变调允许你有一个整洁和线性的git历史并且肯定有它的好处，但这里有一些想法为什么“合并”有时可能优于“变基”，即使你在“写”控制你的分支：

1）避免在合并冲突期间由错误决策导致的不可逆代码删除。

示例：假设您已经在功能分支A工作了两周，现在您停止工作，而是继续在分支B工作两周。 现在经过一段时间后，您觉得是时候再次在分支A上工作了，由于某种原因，您需要将B包含的更改合并到A因此您决定将分支A重新绑定到B 。 在这个变革的过程中出现了几个合并冲突。 由于判断力差或仅仅出现意外，您可以删除A中的部分代码以解决有利于传入更改的冲突。 现在，您继续并完成您的rebase并强制将您的代码推送到遥控器的origin/A 突然间，您意识到您删除了分支A中代码的部分重要且不应删除的代码。 但是，由于rebase重写历史记录，与合并不同，您不能简单地还原rebase并且代码丢失。

如果你告诉你的团队中的小辈总是喜欢重组而不是通过在合并冲突过程中做出错误的决定来删除他们的代码，特别是在将他们的分支重新定位到master上时，上述情况尤其成问题。

当然，除了使用git merge之外，解决这个问题的方法是在执行rebase之前建立备份分支。

2）避免在交互式变基时解决太多冲突。

当您的功能分支包含多个提交时，即您将代码移动了很多甚至可能来回，然后重新定位可能需要比合并更长的时间，因为rebase将按顺序 （！） 顺序通过您的分支提交并在每次发现的冲突中停止。 通过合并，您只需将功能分支的当前状态（即HEAD与您要重新绑定到的分支的HEAD （例如master ）进行比较，并且可能在执行合并时根本没有冲突虽然在做一个rebase时可能会有一些冲突。 所以在这个意义上，合并可能会为您节省一些时间。