Question

说，变基涉及两个分支A和B。我是唯一更改那些分支的人，但是还有其他人拉这些分支只是为了查看正在发生的事情（查看）。他们尚未/将不会对这些分支进行任何更改。考虑到rebase与merge的优缺点，对于

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

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

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

我了解rebase和merge之间的区别，以及在其他开发人员提交父分支的情况下如何出错。

即使我是这两个与基础调整有关的分支机构的唯一开发人员，我也应该避免这种情况吗？？在重新部署基准站后我强制推送并且其他团队成员尝试拉出这些分支（再次只是为了查看它们，他们没有进行任何更改）之后，可能会出什么问题？

Answer 1

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

在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'

重新设置已创建了两个新的提交C4'和C5'，而不是C4和C5，并将分支指针移到了C5'。这里的历史记录是干净的链接列表（因为将重新创建分支提交并将其应用于完成基础的分支），但是创建了两个新的提交，这意味着分支2的历史记录已更改 >（之前为C1 <-C4 <-C5）。因此，每次重新设置基准时，都必须强制执行。

现在回答您的问题：

即使我是这两个与重新定级有关的分支机构的唯一开发人员，我也应该避免这种情况吗？在最佳实践中，最好将功能分支与父分支重新建立基础，然后再将功能分支合并到父分支中，因为功能分支是您自己的分支，但父分支也会有其他开发人员提交，如果您将父分支与功能分支建立基础，而没有从远程获取拉动，则可能会丢失。
在重新设基后我强行推入并且其他团队成员尝试撤消这些契合之后，可能会出什么问题？强制推送，将本地系统上的所有历史记录推送到远程，都将变得非常糟糕。如果您不使用强制推送，那么在历史记录不匹配且提交转换的情况下，您的推送将被拒绝，并且系统会要求您进行推送。另外，如果您在父分支上强加了其他开发人员提交的提交，但没有在本地计算机上提交，则会丢失该提交。

如果其他开发人员试图从远程撤出，他将遇到树冲突，因为他的本地历史记录不会与远程发生冲突。

Answer 2

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

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

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

由于git无法得知新的提交是基于重新提交还是完全不同，因此它将保留旧的重新提交前的提交并将其与重新提交后的提交合并。无论哪种情况，即使代码相同，他们计算机上的提交历史也将始终与您的计算机不同。

Answer 3

重新定级时，您的“黄金法则”有一个扩展版本：

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

展开后的版本如下所示：仅对分支名称使用rebase或其他强制类型的运动，其中该名称的所有用户应预期会导致的行为< / em> 。这是因为每个这样的用户可能都必须采取一些措施才能从该操作中恢复（“上游重新定位”）：即，他或她可能必须“营救”他或她的承诺。如果所有用户都准备这样做，并且知道要查找这种情况，那么他们对这个问题不会感到惊讶。

换句话说，如果您有一个由五个程序员组成的团队，并且你们中的五个人都同意“ pu”（“建议的更新”或“提取”分支）一直都在重新设置基础，则可以重新设置pu分支。如果你们中的一个人可以重新建立“ develop”分支，但四个人不是，那么重新组织“ develop”分支也是 not 。

由于您是与A和B一起工作的唯一用户和开发人员，因此由您来决定是否同意为A和/或B重新设置基础是否可以。

Answer 4

在重新定基后我强行推入并且其他团队成员尝试拉开这些分支（再次只是为了查看它们，他们没有进行任何更改）之后，可能会出什么问题？

没有任何事情真的可以“错”。可能发生的最糟糕的情况是，“查看者”在合并时会遇到不必要的麻烦，因为您新近强行提交的提交可能看起来完全不同，现在results in merge conflicts来进行拉取（即获取和合并）。

即使我是这两个与基础调整有关的分支机构的唯一开发人员，我也应该避免这种情况吗？

虽然重定基可以让您拥有tidy and linear git history并肯定有其好处，但是这里有一些想法，即使您处于“写”-控制权下，为什么有时“合并”比“重定”更可取您的分支机构：

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

示例：假设您已经在功能分支A上工作了两个星期，现在您停止使用它，而是继续在分支B上工作了两个星期。现在过了一段时间，您觉得是时候再次在分支机构A上工作了，由于某种原因，您需要将B中包含的A中包含的更改进行更改，因此您决定重新建立分支机构{{1 }}移至A上。在此重新设置的过程中，会发生一些合并冲突。由于判断力很差或很偶然，您删除了B中的部分代码以解决冲突，以利于传入更改。现在，您继续并完成基础，并强制将代码推送到遥控器的A。突然您意识到，您删除了分支origin/A中重要的部分代码，这些部分不应该被删除。但是，由于rebase会重写历史记录，因此与合并不同，您不能简单地还原rebase并丢失代码。

如果您告诉团队中的初级人员总是更喜欢使用基础而不是合并，并且在合并冲突过程中，他们由于做出错误的决定而意外删除了他们的代码，尤其是在将分支重新部署到{{时， 1}}。

当然，除了使用A以外，解决此问题的方法还包括在执行重新设置基准之前创建备份分支。

2）为避免在交互进行基础调整时解决太多冲突。

当您的功能分支包含多个提交时，即，您将代码移动了很多甚至可能来回移动，那么重新定基可能要比合并花费更长的时间，因为重新定基将依次执行（！）通过分支的提交逐个提交，并在发现的每个冲突处停止。合并后，您将只比较功能分支的当前状态，即master与您要基于其迁移的分支的git merge（例如，HEAD），并且可能在执行合并时完全没有冲突，而在进行重新设置时可能存在一些冲突。因此，从这个意义上讲，合并有可能为您节省一些时间。

当我是两个相关分支中的唯一成员时，我应该使用git rebase而不是git merge

4 个答案: