Git 工作流程 - 扩展分叉 - 如何协调分歧的分叉？

Question

这一定是一个很好理解的问题，但我似乎无法找到相关信息。

TL；DR：由于分支历史混乱，git 在两个分支代码之间的映射似乎被破坏了。

设置：

我正在维护一个“扩展”叉。 IE：

我有一个fork存储库，它是origin的副本。 （而且我有一个本地存储库，用于区分fork和origin远程。）
Fork 包含项目的自定义扩展。 我将更改提交到fork/master 。
每当有origin/master更新时，我将其合并到fork/master中。 （即，我直接获取并合并origin/master到本地存储库并推送到fork/master 。）
随着时间的推移，'fork/master' 有时会显着偏离 master，但稍后会再次收敛，因此大部分代码仍处于“1-1”关系。

这样，“发散”提交会在fork/master （数百个）上累积。 最近，我在解决冲突方面遇到了（越来越多的）问题：

Git 合并产生了很多原因不明的冲突。
Git 合并经常错误地自动解决冲突。 实际上，这意味着在合并之后，我经常会在“随机”位置发现插入或删除的“随机”代码片段。 这些更改是完全错误的，但无需我审查即可应用。
（代码部分之间的代码映射完全被破坏了，这显然是问题的原因，但无法手动查看合并提交中自动应用的更改。）

我认为原因是三向合并，它试图考虑自第一次分歧提交以来分支的整个提交历史。

我试图在origin/master之上将 fork “rebase”为一个压缩提交，并将这个分支合并到fork/master中：

git checkout -b master_rebased master
git reset --soft origin/master
git commit
git checkout master
git merge master_rebased`

这种方式fork/master现在实际上有两个替代历史。 我认为 git 在计算合并或发散统计数据之前总是会自动计算“最短”发散路径（完全包含整个变更集），但不会 - git 仍然声称我的分支在origin/master之前有数百个提交。

当然，我可以简单地扔掉旧的fork/master并用重新定位的 master 替换它，但这听起来是一种非常不清楚的处理问题的方法，这可能意味着我遗漏了一些东西。

所以问题基本上是：

1）协调分歧分支的最干净的方法是什么？

2) 什么是正确的 git 工作流程来维持长期扩展叉？

3）或者：我错过了什么？

Answer 1

或者：我错过了什么？

好吧，我显然错过了正确的搜索关键字 - “长期存在的主题分支”或“长期存在的功能分支”。

什么是正确的 git 工作流程来维持长期扩展叉？

搜索导致了一堆方法，但是没有发现任何新的东西。 推荐的方法是：

简单地使用合并。 显然不能解决我的问题，但这是最简单的方法，除非出现冲突解决问题。
使用变基，同时重写/丢弃提交历史。
这条评论https://stackoverflow.com/a/7752610/6922501展示了如何处理重写他人历史的问题 - 基本上，让受影响的一方将他们的工作重新定位到重新定位的分支上。
使用git rerere，它基本上记录了合并冲突的解决方案，并在同一冲突多次出现时自动重播。

协调分歧分支的最干净的方法是什么？

在这一点上我仍然不清楚，但似乎最终，一个人必须选择 rebase 或 merge+rerere 及其所有后果（好的和坏的）。

资料来源：