我需要定制一个开源项目。这些更改是针对特定组织的，对公共项目没有用处。代码更改包括禁用组织不需要的功能（影响 5% 的代码）、为组织定制其他功能（影响 20% 的代码）以及添加新的自定义功能（添加大约 10% 的新代码）。
我可以从当前版本开始并从那里进行自定义。但是，原始项目继续取得进展并引入新功能，我希望能够在这些改进出现时将其纳入。
管理此问题的最佳方法是什么？现在，我只能在发布版本可用时获得它们，但我应该很快就可以只读访问原始项目的 Subversion 存储库。我是使用 Subversion 存储库的新手，但也可以将它们用于我的代码。
最佳实践是首先尝试将您的更改合并到项目中。
如果这不是一个选择，你只是
第 3 步和第 4 步与您的前叉保持最新有关。这是很多工作，取决于项目的活动和保持最新状态的重要性。如果非常重要，我会每周至少更新和合并一次。
您可能更喜欢将他们的 svn 树导入 git 以简化合并，这是您最常做的事情
最好的办法是不要分叉它。为什么不弄清楚如何改进它，这样它就可以做你想做的事情并且不会丢失任何现有的功能。如果代码大小是一个问题，也许你可以花一些时间来提高现有项目的效率。
我认为将您的东西放到上游是最安全的方式，因为您可以免费获得所有错误修复，并且上游所做的更改不会破坏您的东西，因为其他贡献者也必须尊重您的“功能”，因为他们是项目中的一等公民. 如果这不是一个可行的选择，我会说带有颠覆桥的git是要走的路，因为它已经有很多对分叉有用的功能，这是在 git 中做事的自然方式，因为一切都是一种不同回购的叉子。
你和项目负责人谈过吗？您的更改是否具有普遍意义，还是非常适合您的需求？如果你不能在主项目中做你需要的工作，你当然可以分支他们的树，只要继续合并就行了。
您也可以查看 GIT 之类的功能（它可以与原始 svn 很好地交互）以接受部分合并/补丁。分歧越大，这个问题就越严重。当然，您可以使用 svn 和一个好的编辑器来完成，但使用更灵活的工具可能会使您的生活变得更轻松。
这是 Visko 建议的变体，相反的假设是您将花费大部分时间进行自己的更改，并且只是偶尔集成原始源项目的新版本。（使用下面的颠覆词汇。）
创建项目，将 original-source 作为主干提交。标签。
当您进行本地更改时，根据需要使用分支，合并回主干以进行发布等。
当您想要集成原始源项目的新版本时：
这就是我在脑海中设计的供我自己使用的过程。希望得到反馈。
导入原始项目的 subversion-dump 并使用自己的存储库作为分支启动您的 fork - 随着原始项目的改进，您可以导入更改，然后调用“svn merge”来合并这些改进。只要您和原始项目不进行一些重组（重命名源文件，在目录之间移动等），合并应该主要工作。