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 及其所有后果（好的和壞的）。

資料來源：