自定义功能的 Git 分支策略

Question

我想就我正在从事的项目的最佳 Git 分支策略获得一些建议。

有一个开源程序（我将其称为“PRIMARY”），我想对其进行分叉并添加几个专门的功能（我将此修改后的版本称为“SPECIAL”）。这些功能（我将它们称为“FEATURE1”和“FEATURE2”可能通常不足以保证将它们添加到 PRIMARY 的主线开发中，但我想让 FEATURE1 或 FEATURE2 的更改可供任何想要的人使用他们。PRIMARY 正在积极开发中，我希望 SPECIAL 及时了解这些变化以及我的功能继续添加。

我的目标是创建一个公共存储库，以便于

1. 使用新版本 PRIMARY 的更改更新 SPECIAL；
2. 创建新版本的 SPECIAL 并添加 FEATURE1 和 FEATURE2；
3. 隔离必要的更改以将 FEATURE1 或 FEATURE2 添加到任何版本的 PRIMARY。

我一直在尝试各种策略，但我觉得我还没有找到最佳解决方案。我最初的想法是使用 master 分支进行 SPECIAL，一个供应商分支跟踪 PRIMARY 的更改，从供应商分支分支 FEATURE1/FEATURE2，然后将功能分支合并到主分支以生成最终的 SPECIAL 程序。但是如何处理 PRIMARY 的更新呢？我的所有尝试都需要在 PRIMARY 更新时手动对多个分支进行相同的更改（并解决冲突）。这对我来说似乎是错误的，而不是 DRY。

建议？

Answer 1

问题是，如果您分叉，您将不得不自己维护原始项目 (PRIMARY) 的更新。这不是一个好习惯。想象一下，该项目越来越受欢迎（如果还没有的话）并获得了 1000 多名开发人员。您必须及时了解他们的所有更新。

第一个选项是分叉项目，实现 FEATURE1、FEATURE2，然后要求他们合并更改。由于您已声明：“... are probably not generally useful enough to warrant them being added to the mainline ...”，此选项失败。

这让我想到了第二个选项。如果这些功能对主线没有用，也许你不应该一开始就分叉。也许你应该有一个自己的小项目，它依赖于开源项目，并且只包含这 2 个特性的功能。把它想象成一个插件。

但是，假设您想坚持自己的方案。在那种情况下，我肯定会有至少 6 个分支：

• master - 发布我自己的分支
• vendor - 跟踪原始项目的更新
• development - 跟踪我的开发和原始项目的更新
• feature1 - 暗示
• feature2 - 暗示

featureX 分支是不言自明的。在vendor 分支中，原始项目的所有更改都将被合并（努力工作）。 development 分支是将 vendor 和 featuresX 合并到的分支。一旦代码能够正常工作，development 分支应该合并到 master 中，并且应该有一个新版本。

另外，vendor 分支不必具有原始项目中的所有更改。您只能从其发布分支更新vendor 分支。

我认为这应该是一个关于如何进行分支的好文档：http://nvie.com/posts/a-successful-git-branching-model/