我的情况是，我提交给开源项目的一些小补丁被忽略或明确不被接受。 我认为它们很有用，但更重要的是我需要它们实现的功能。
我不想再把我的想法和建议推给主要贡献者，因为我不想把它变成一个自我问题。我已经决定我最好的选择就是将我写的东西用于我自己的目的。我不想分叉整个源代码树，因为我喜欢事情的一般运作方式，我只是对细节不满意。
但我确实意识到该项目会不断发展，我希望使用最终会出现的新功能。我知道我必须将所有新事物合并到我自己的源代码树中。这种情况有什么最佳做法吗？
【问题讨论】：
标签： version-control open-source
标准方法是在您的存储库中维护供应商分支。这个想法是您将原始源的原始副本（称为 vendor drop）导入本地存储库，并将其存储在分支中。这是应用模组之前的代码版本。你用版本标记它，然后将它复制到主干并应用你的补丁。
当供应商代码的后续新版本发布时，您检查供应商分支（没有您的模组），并将新版本覆盖在顶部。最后，您将新分支与您的 mod 合并，检查它们是否仍然适用/相关，并且您已准备好再次使用。
可能会有并发症，例如文件被重命名、删除等。Subversion 附带的脚本svn_load_dirs.pl 可以帮助您识别已更改名称的文件并自动化一些官僚机构。
Subversion 书籍的Vendor Branches 部分下详细讨论了这种方法（而且更清楚）。
【讨论】：
如果您正在使用Git，或者可以习惯使用它，也许您应该看看Stacked Git 或Guilt。
它们是 Git 之上的层，用于跟踪补丁。
【讨论】：
通常您会在存储库中创建项目的一个分支。在您的具体情况下，如果可能的话，我会创建一个仅包含您的代码的目录的分支。很多像 subversion 这样的存储库将允许您在主干旁边检查您的分支。这应该允许您维护您的补丁并确保它们与将来对主干所做的更改一起使用。
【讨论】：