18

概述

我有一个项目是对现有 FOSS 产品的定制。它达到了我们维护长期分叉而不是应用新插件等的地步。我想要一些关于维护这个项目的最健全的工作流程可能是什么的输入。

标准

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

选项1

只需在 github 上 fork 项目即可。维护和让人们加快速度超级混乱。失败 3,4。

选项 2

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

选项 3

分叉上游项目，将其用作选项 2 中的上游。用作 PR 系统的助手。根据功能/错误分支的管理情况，可能需要进行樱桃挑选或一些类似的微管理来推动代码备份此工作流程，但应该相当干净。似乎满足大多数标准。

选项 ？

我没有考虑过的东西？

4

1 回答 1

5

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

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

为了便于合并，我建议在您的存储库中使用分层分支名称，以便清楚地分开：

  • 项目开发的分支（经典名称，其中不需要“ /”）
  • 来自上游/原始 repo 的分支（所有前缀都以代表原始 repo 分支的名称为前缀，例如' original/dev'，供您从中挑选或选择）
    这些分支已经在它们的远程/上游命名空间中，但是如果你想要要推回新的提交，您需要创建一个本地分支，我的观点是：该本地分支的名称中应该有一个“ /”，以便清楚地将其与您项目的其他常规分支区分开来。
于 2014-03-18T06:28:24.647 回答