用于维护衍生分叉的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为了清楚地将其与您项目的其他常规分支机构区分开来。