我的团队在一个分叉的gitlab repo (origin)上工作。当团队成员完成了向原始提交的推送后，我们向上游的repo发出合并请求。
合并请求由另一个团队批准，无论如何，我们对上游没有治理。此外，我们从不直接向上游推送。
当合并请求等待批准时，我的团队继续向原点推进。
问题是，每次我们想要发出一个新的合并请求(前一个已经被批准)，我们发现自己无法重新定位到上游。新的合并请求既包含新的提交，也包含已经在上游合并的所有提交。我们最终发出新的合并请求，一旦它被批准，我们就硬复位到上游并强制推送到原点:
git fetch upstream
git reset --hard upstream/main
git push --force
显然，这是错误的。当合并请求被批准并且有新的提交到原点时，为什么我们不能干净利落地重新定位?相反，所有提交(包含在已批准的合并请求中)显示为冲突。
我们如何避免每次都硬重置原点?
听起来像是上游存储库的维护者在合并时重写了历史-最有可能的是，他们使用了"压缩合并"，这将丢弃所有的历史，并创建一个合并所有更改的单一提交。
理想的做法是向他们指出这会给你带来多少额外的工作，并要求他们使用真正的合并(合并提交)，这样git就可以跟踪分支之间的关系。
假设你不能这样做，你将需要在某个时候重置/重置更改到他们的新历史。但是，您可以通过避免长时间运行的分支来简化此操作:
- 你开发的每个功能都应该是它自己的分支。
- 你的合并请求应该来自这些分支之一，而不是你的分支的"main"。这样，你就不需要合并到本地的"主"版本，也不会与上游版本不同步。
- 在可能的情况下，直接从最新的上游"main"启动新的功能分支。
- 如果你需要把你的一个特性建立在另一个特性上，一旦上游接受了第一个特性，你就需要重新建立它。具体来说，您需要rebase命令的三个参数版本，我记得是"git rebase old_base old_tip—onto new_base";("将从old_base到old_tip的提交重新定位到new_base")，例如
git rebase feature-42 feature-43 --onto upstream/main
总之，完全忽略"main"在你的fork (origin)上建立分支，并且总是使用"main"。在中心副本上的分支(上游)。不要从origin/main创建任何分支，不要提交到那个分支，也不要在那里合并任何东西。