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

Question

概览

我有一个项目是对现有 FOSS 产品的定制。它已经到了我们维护长期分支而不是应用新插件等的地步。我想就维护此项目的最合理工作流程可能是什么提供一些意见。

标准

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

选项1

只需在 github 上 fork 项目即可。维护起来 super 困惑，让人们加快速度。失败 3,4。

选项 2

创建一个新的存储库，让项目维护人员根据需要引入上游代码库的标记版本。例如像 git fetch upstream; git merge upstream/sometag taintegrationbranch 不确定如何在此模型中轻松地将修复推送到上游。有点失败 1.

选项3

fork 上游项目，像选项 2 一样将其用作上游。用作 PR 系统的助手。可能需要进行挑选或一些类似的微观管理，以根据功能/错误分支的管理程度将代码推回此工作流程，但应该相当干净。似乎满足大多数标准。

选项 ?

我没有考虑到什么？

Answer 1

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

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

为了便于 merge ，我建议使用 hierarchical branch names在你的 repo 协议(protocol)中，为了清楚地分开:

• 项目开发的分支(经典名称，其中不需要“/”)
• 来自上游/原始存储库的分支(所有前缀都带有表示原始存储库分支的名称，例如“original/dev”，供您从中挑选或从中挑选)
  这些分支已经在它们的 remotes/upstream 命名空间中，但是如果你想推回新的提交，你需要创建一个本地分支，我的观点是:那个本地分支的名称应该有一个 '/'，以便与您项目的其他常规分支清楚地区分。