用於維護衍生分叉的Git工作流程

Question

概觀

我有一個項目是現有FOSS產品的定制。 它達到了我們維持長期分叉而不是應用新插件等的程度。 我想對維護這個項目的最佳工作流程提出一些建議。

標准

1. 我們應該能夠輕松地向上游發送拉取請求/補丁
2. 該項目需要跟蹤標記版本，並可能作為我們自己的發布工作流程的一部分更新到新版本。
3. 需要有自己的標記版本
4. 需要有自己的分支結構，用於git-flow開發過程。

選項1

只需在github上分叉項目。 超級凌亂維持並讓人們加快速度。 失敗3,4。

選項2

創建一個新的存儲庫，讓項目維護者根據需要提取上游代碼庫的標記版本。 例如git fetch upstream; git merge upstream/sometag tagintegrationbranch git fetch upstream; git merge upstream/sometag tagintegrationbranch不確定如何在此模型中輕松推送上游修復。 有點失敗1。

選項3

分叉上游項目，將其用作選項2中的上游項目。用作PR系統的助手。 可能需要做一些櫻桃選擇或一些類似的微觀管理來推動代碼備份這個工作流程，具體取決於功能/錯誤分支的管理程度，但應該相當干凈。 似乎滿足大多數標准。

選項 ？

我沒有考慮過的事情？

Answer 1

選項3似乎代表了兩個項目之間最清晰的工作流程分離：

• 一個偶爾回饋原始項目的人，有拉請求
• 一個具有全新分支和新應用程序的代碼

為了便於合並，我建議在您的倉庫中使用分層分支名稱 ，以便明確區分：

• 項目開發的分支（經典名稱，不需要' / '）
• 來自上游/原始倉庫的分支（所有分支都帶有一個代表原始倉庫分支的名稱，如' original/dev '，供您選擇或從中挑選）
  那些分支已經在他們的遙控器/上游命名空間中，但是如果你想要推回新的提交，你需要創建一個本地分支，我的觀點是：該本地分支的名稱中應該有一個' / '，in為了清楚地將其與您項目的其他常規分支機構區分開來。