当我是唯一处理两个相关分支的人时，我应该使用git rebase而不是git merge吗

假设rebase包含两个分支

A

和

B

。我是唯一一个对这些分支进行更改的人，但是还有其他人拉这些分支只是为了查看正在发生的事情（查看）。他们根本没有/不会对这些分支机构进行任何更改。考虑到重组与合并的利弊，重组显然是一个更好的选择

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

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

并解释了为什么它会很危险

我理解rebase和merge之间的区别，以及在有其他开发人员承诺使用父分支的情况下如何出错

---

即使我是这两个分支中唯一一个关注重定基址的开发者，我是否应该避免这种情况？在我在重新设置基址后强制推送，而其他团队成员尝试拉取这些分支（再次只是为了查看它们，它们没有做任何更改）之后，可能会出现什么问题？

要确定是使用重新设置基址还是合并，首先需要了解它们的工作原理

在git中，提交是链表链，后一个提交引用了前一个提交

C1<-C2<-C3<-C4

---

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

Git将获取重定基础的提交，并尝试将其与reviewer的分支合并

这将创建一个合并提交（如果一切顺利），或者导致合并冲突

因为git无法知道新的提交是重定基础的还是完全不同的，所以它将保留旧的重定基础前提交，并将其与重定基础后提交合并。在这两种情况下，即使代码相同，他们机器上的提交历史记录也将始终与您的不同。
关于重定基址，您的“黄金法则”有一个扩展版本：

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

扩展版本如下：仅在分支名称上使用rebase或其他强制推送类型的运动，该名称的所有用户都希望得到结果。这是因为每个这样的用户可能必须采取一些行动来从这样的操作中恢复（“上游重新基准”）：即，他或她可能必须“挽救”他或她的承诺。如果所有用户都准备这样做，并且知道如何查找此类案例，那么他们不会对问题感到惊讶

换句话说，如果您有一个由（比如）五名程序员组成的团队，并且所有五名程序员都同意“pu”（“建议的更新”或“拾取”分支）一直都在重新设置基址，那么重新设置pu分支的基址就可以了。如果你们中的一个对“develope”重定基址没问题，但有四个不行，那么对“develope”分支重定基址是不好的

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

在我在重定基址后强制推送，而其他团队成员尝试拉取这些分支（再次只是为了查看它们，它们没有做任何更改）之后，可能会出现什么问题

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

我是否应该避免这种情况，即使我是这两个分支中唯一一个关注重定基准的开发者

虽然重定基址可以让您拥有一个更好的分支，而且肯定有它的好处，但以下是一些关于为什么“合并”有时比“重定基址”更可取的想法，即使您对您的分支具有“写”控制权：

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

示例：假设您已经在功能分支
A
上工作了两周，现在您停止了工作，而是继续在分支
B
上工作了两周。现在，经过一段时间后，您觉得是时候再次处理分支
A
，并且出于某种原因，您需要将
B
中包含的更改合并到
A
中，因此您决定将分支
A
重设为
B
。在重新调整基础的过程中，出现了几个合并冲突。由于判断错误或纯属偶然，您删除了
A
中的部分代码，以解决冲突，从而支持传入的更改。现在，您继续并完成重基，并强制将代码推送到遥控器的
原点/A
。突然，您意识到您删除了分支
A
中重要的、不应该删除的部分代码。但是，由于rebase重写历史，与合并不同，您不能简单地恢复rebase，代码将丢失

如果您告诉团队中的年轻人总是更喜欢重基而不是合并，并且他们在合并冲突过程中做出错误的决定，特别是在将分支重基到
主节点上时，意外地删除了他们的代码，则上述情况尤其成问题

当然，除了使用
git merge
之外，这个问题的解决方案是在执行重基之前创建一个备份分支

2） 以避免在交互重定基址时解决过多冲突

当您的功能分支包含多个提交时，也就是说，您将代码移动了很多，甚至可能前后移动，那么重定基址可能需要比合并更长的时间，因为重定基址将依次（！）通过分支的提交，并在发现的每一个冲突时停止。通过合并，您将只比较当前状态，即要素分支的
头
，与您正在重定基础的分支的
头
（例如
主
）可能存在
C1<-C2<-C3
 \        \
  \       M1
   \      /
   C4<-C5

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

#On branch2
git rebase branch1

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