用於維護項目擴展分支的Git工作流程？

Question

我們在GitHub上分叉了一個OSS項目，並為它添加了一些自定義擴展。 我們希望將我們做出的一些更改發送回原始項目（錯誤修復等），但其他更改是原始項目維護者目前不感興趣的功能擴展。 我正在努力找出管理這種情況的最佳工作流程。

我希望我們的主分支包含（來自原始項目的提交）+（我們的貢獻的錯誤修復）+（我們的自定義擴展）的總和。 我想我們需要一個按功能分支的模型，以便我們可以將錯誤修復與自定義擴展分開。 我們可以從我們的主分支啟動自定義擴展分支，但我想我們也想要維護一個本地“origin”分支或者跟蹤原始項目的東西，以便我們可以從那里啟動沒有被我們的污染的bugfix分支。定制的東西。 或者其他的東西。

任何人都可以建議最好的方法來構建這個工作流程，以便所有各種提交都去他們應該去的地方，沒有人去他們不應該去的地方？

Answer 1

聽起來像你已經回答了自己的問題。 創建一個名為“vanilla”的分支或跟蹤上游主分支的東西，並有一個包含自定義擴展的“主”分支。 為你做的每件事創建分支。 對於錯誤修正，請從“香草”開始。 對於你自己的東西，從主人開始。 每隔一段時間，將香草合並為主人。 要將錯誤修正帶到您的自定義擴展分支中，您可以直接將它們的分支合並到主服務器中，或者只是等待上游接受您的錯誤修復請求，然后從vanilla到master的下一個合並將包含錯誤修正。 這似乎是一個非常正常的工作流程。

Answer 2

您要設置的是一個長期的分支 ，為此您已經發現解決方案可能是設置一個與原始“vanilla”項目鏈接的特殊分支，並有一個主分支，您可以在其中維護自定義工作副本。

你需要記住的唯一一件事（從我的角度來看）是你想要同步變化時不應該合並兩個分支，但在這種情況下（ 當分支發散時 ）有方便的Git Cherry-選擇命令，允許您從一個分支進行單個提交並將其應用到另一個分支 ，這在維護分支的情況下特別有用，因為您可以輕松地將單個提交從一個分支交換到另一個分支...