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

Question

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

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

The golden rule of git rebase is to never use it on public branches.

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

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

即使我是这两个与 rebase 相关的分支的唯一开发人员，我是否应该避免这种情况？在 rebase 后我强制推送并且其他团队成员尝试 pull 这些分支(再次只是为了查看它们，他们没有进行任何更改)之后可能会出现什么问题？

Answer 1

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

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

C1<-C2<-C3<-C4

当两个分支 merge 时，将创建一个新的 merge 提交(下面用 M1 表示)

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

对正在 merge 的提交有引用。在这里，历史不再是链表。变成了有向无环图。

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 的分支)，但是创建了两个新的提交，意味着分支2的历史发生了变化(之前是 C1<-C4<-C5)。因此，每次进行 rebase 时都必须强制推送。

现在回答你的问题:

1. 即使我是这两个与 rebase 有关的分支的唯一开发人员，我是否应该避免这种情况？ 在最佳实践中，始终将您的功能分支与父分支 rebase ，然后将您的功能分支 merge 到父分支，因为功能分支是您自己的分支，但父分支也会有其他开发人员提交，如果您将父分支与功能分支 rebase 而不从远程 pull ，它可能会丢失。

2. 当我在 rebase 后强行推送而其他团队成员试图 pull 这些支撑时，可能会出现什么问题？ 它会变得非常糟糕，因为强制推送，将您在本地系统上的任何历史推送到远程。如果您不使用强制推送，那么您的推送将在不匹配的历史记录和提交转换的情况下被拒绝，并且您将被要求 pull 。 此外，如果您在父分支上强制推送了一些其他开发人员提交的内容，但没有在您的本地计算机上推送，那么该提交将丢失。

如果其他开发人员试图从远程 pull ，他将遇到树冲突，因为他的本地历史不会与远程匹配。