如何避免每次都硬重置分叉？

Question

我的团队在分叉的 gitlab 回购（来源）上工作。当团队成员将他们的提交推送到 origin 时，我们向上游 repo 发出合并请求。

合并请求得到了另一个团队的批准，我们无法对上游进行任何管理。此外，我们从不直接向上游推送。

在合并请求等待批准的同时，我的团队继续向源推送。

问题是，每次我们想要发出一个新的合并请求（并且之前的一个已被批准）时，我们发现自己无法变基到上游。新的合并请求包含新的提交和已经在上游合并的所有提交。我们最终发出新的合并请求，一旦获得批准，我们就会硬重置到上游并强制推送到源：

git fetch upstream 
git reset --hard upstream/main
git push --force

显然，这是错误的。当合并请求被批准并且有新的提交到 origin 时，为什么我们不能干净地变基？相反，所有提交（包括在批准的合并请求中）都显示为冲突。

我们如何避免每次都硬重置原点？

Answer 1

听起来上游存储库的维护者在合并历史时正在重写历史 - 很可能，他们正在使用“挤压合并”，这会丢弃您的所有历史并创建一个合并所有更改的提交.

理想的做法是向他们指出这给您带来了多少额外工作，并要求他们使用真正的合并（合并提交），以便 git 可以完成跟踪关系的工作树枝之间。

假设您不能这样做，您将需要在某个时候将更改重置/变基到他们的新历史记录中。但是，您可以通过避免长运行分支来简化此过程：

您开发的每个功能都应该是它自己的分支。
你的合并请求应该来自这些分支之一，而不是你的分支的“主要”。这样，您就不需要合并到您本地的“主”，它也不会与上游不同步。
如果可能，直接从最新的上游“main”开始新的特性分支。
如果您需要将您的一个功能基于另一个功能，您将需要在上游接受第一个功能后对其进行变基。具体来说，您需要 rebase 命令的三参数版本，我记得它是“git rebase old_base old_tip --onto new_base”（“rebase the commits from old_base 到 old_tip 到 new_base")，例如git rebase feature-42 feature-43 --onto upstream/main

简而言之，完全忽略你的分支（起源）上的“主要”分支，并始终使用中央副本（上游）上的“主要”分支。不要从 origin/main 创建任何分支，不要提交到那个分支，也不要在那里合并任何东西。

How to avoid hard resetting a fork, every time?