我們是一個由幾個開發人員組成的團隊，擁有主分支並在功能分支中開發功能。當我們發佈時，我們會分支 master 的發布分支。所有錯誤修復都是在 master 中進行的，然後精選到相關的發布分支中。
我們希望對每個新功能進行原子合併提交，我們可以回滾並一分為二，如中所述https://gist.github.com/jbenet/ee6c9ac48068889b0912。它應該給我們一個看起來像這樣的歷史。
* aa55ffe - (HEAD, master) D
* 88425f8 - C
* 7bc519f - Merge branch 'feature-X' into master
|\
| * 9364e61 - feature-X: 2
| * bc76674 - feature-X: 1
|/
* 88425f8 - B
* 7bc519f - Merge branch 'feature-Y' into master
|\
| * 0e0deea - feature-Y: 4
| * 11079b5 - feature-Y: 3
| * 9364e61 - feature-Y: 2
| * bc76674 - feature-Y: 1
|/
* c765ae3 - A
當我們有多個開發人員致力於相同的功能追蹤到我們的功能分支的遠端版本時，我們的問題就變成了。因為雖然一些開發人員致力於該功能，但錯誤修復可能是在 master 的功能開發過程中發生的。我們現在希望將這些錯誤修復包含在功能分支中（即在修復了錯誤的 master 中重新調整新狀態的功能分支。）。
有沒有一種方法可以做到這一點，而不包括破壞遠端追蹤分支，從而搞砸乾淨的歷史記錄和其他功能開發人員的工作副本？
Fx 是否可以將 bug 挑選到功能分支中，並讓 git 在最終 rebase 之後自動解決它，在將新的 rebase 版本的功能分支合併到 master 之前，我們孤立遠端追蹤分支？
答案1
是否可以將錯誤挑選到功能分支中並讓 git 自動解決它
如果您的修復不會引入衝突，則此方法可行。git clone https://gist.github.com/jbenet/7959265，查看歷史記錄並閱讀我貼在那裡的引用日誌。
如果您在挑選時解決衝突，則可以在合併 PR 之前在 master 之上重新建立基礎時手動刪除提交（您可以在解決衝突的提交訊息中對其進行標記/寫入提醒）。
但在我看來，當修補程式可用時，我會在 master 之上重新建立功能分支。這與從 master 拉取任何更改相同（包括最近合併的其他功能分支）。因此，您不必擔心您的分支已經過時。取決於您的團隊喜歡處理什麼 - 刪除合併的修補程序，或經常變基。
答案2
如果您確實需要功能分支中的錯誤修復，請合併錯誤修復分支。在那篇文章中提出的模型會產生人為的問題（例如您提出問題的問題），並且從字面上看，它唯一的好處是更清潔看著歷史。在意識到不變基的好處之前，我們使用了這個模型幾年。當我需要清理自己的歷史記錄（壓縮提交、更改提交訊息等）時，我會重新設定基準，但它不會影響下游的任何其他人（就像我正在單獨處理分支一樣）。