git - 宣布 git push -f 而其他人都在做 git pull --rebase 有什么不好

Question

假设

• 你在 github 上 fork 了一个项目
• 多人(少于 5 人)正在使用这个 fork
• 目标是对我们的更改提出 pull 请求

在对我们的分支进行几次提交之后，我们现在想要将我们的分支更新为源项目中的最新 HEAD。因为多人在这个分支上工作，所以标准方法是 pull 下源项目，然后进行 merge 提交以从源项目中引入最新的 HEAD。

我们不喜欢这样，因为它使我们的历史变得非线性，我们将有许多“无用”的 merge 提交。

我们的替代想法是:

1. git pull --rebase 使本地有最新的forked HEAD
2. rebase 我们的 fork 以引入新的最新 HEAD 源，这样我们的提交就在源 HEAD 之后
3. git push --force
4. 其他人将通过 git pull --rebase 获得最新信息(我们可以为每个人设置默认值)

历史是线性的，只是为 fork 的提交者进行了一些协调。

这种方法有什么问题？

Answer 1

你从这里开始(U 是上游，Y 是你的):

UB--U1--U2
 \
   Y1--Y2

现在你做一个 rebase (和push -f):

UB--U1--U2--Y1'--Y2'

现在您的其他团队成员pull --rebase:

UB--U1--U2--Y1'--Y2'--Y1''--Y2''

正如 robinst 指出的那样——如果你必须解决冲突，git 不会注意到 repo 协议(protocol)中已经有 Y1 和 Y2 的版本，只需再次 rebase (也可能会产生一些丑陋的冲突)。

我只建议进行 merge (您可以查看您的线性历史记录 git 日志 --no-merges)。如果你真的想尝试 rebase 方式，这就是 你可以这样做:

你跑:

git fetch --all
git branch rebase_base master
git push origin rebase_base
git rebase upstream/master
git push -f origin master

然后其他人都运行:

git fetch origin
git rebase --onto origin/master origin/rebase_base master

查看 git help rebase 了解其工作原理 ;)。基本上你告诉 git 直到你已经做了 rebase (rebase_base) 的提交，所以它不会 rebase 不需要它的东西。