用于维护衍生分叉的Git工作流程

Question

概述

我有一个项目是现有FOSS产品的定制。它达到了我们维持长期分叉而不是应用新插件等的程度。我想对维护这个项目的最佳工作流程提出一些意见。

标准

1. 我们应该能够轻松地向上游发送拉取请求/补丁
2. 项目需要跟踪标记版本，并且可能会作为我们自己的发布工作流程的一部分更新到新版本。
3. 需要拥有自己的标记版本
4. 需要为git-flow开发过程提供自己的分支结构。

选项1

只需在github上分叉项目。超级凌乱维持并让人们加快速度。失败3,4。

选项2

创建一个新的存储库，让项目维护者根据需要提取上游代码库的标记版本。例如git fetch upstream; git merge upstream/sometag tagintegrationbranch之类的东西不确定如何轻松地在此模型中向上游推送修复。有点失败1。

选项3

分叉上游项目，将其用作选项2中的上游项目。用作PR系统的助手。可能需要做一些樱桃选择或一些类似的微观管理来推动代码备份这个工作流程，具体取决于功能/错误分支的管理程度，但应该相当干净。似乎满足大多数标准。

选项？

我还没有考虑过的事情？

Answer 1

选项3似乎代表了两个项目之间工作流程的最清晰分离：

• 一个偶尔回复原始项目的人，有拉请求
• 一个具有全新分支和新应用程序代码的文件

为方便合并，我建议您在回购中使用hierarchical branch names，以便明确区分：

• 用于项目开发的分支（经典名称，不需要＆{39; /＆＃39;在其中）
• 来自上游/原始回购的分支（所有回复都带有代表原始回购分支的名称，例如＆＃39; original/dev＆＃39;，供您选择或来自<）登记/> 那些分支已经在他们的遥控器/上游命名空间中，但是如果你想要推回新的提交，你需要创建一个本地分支，我的观点是：该本地分支的名称应该有一个＆＃39; {{1 }}＆＃39;在其中，为了明确区分它与您项目的其他常规分支。