我需要自定义一个开源项目。所做的更改是针对特定组织的，对公共项目无用。代码更改包括禁用组织不需要的功能(影响5％的代码)，为组织自定义其他功能(影响20％的代码)以及添加新的自定义功能(添加约10％的新代码)。

我可以从当前版本开始，然后从那里进行自定义。但是，原始项目会不断取得进步并引入新功能，我希望能够将这些改进纳入其中。

最好的管理方式是什么？现在，我只能获得可用的发行版本，但是不久我应该对原始项目的Subversion存储库具有只读访问权限。我是使用Subversion存储库的新手，但也可以将其用于我的代码。

解决方案

最好的办法是不要分叉它。为什么不弄清楚如何对其进行改进，以便它将按我们希望的方式工作而不丢失任何现有功能。如果代码大小是一个问题，也许我们可​​以花费一些时间来分叉代码，以提高现有项目的效率。

导入原始项目的subversion-dump，并使用自己的存储库作为分支开始fork。随着原始项目的改进，我们可以导入更改，然后调用" svn merge"以合并这些改进。只要我们和原始项目没有进行任何重组(重命名源文件，在目录之间移动等)，合并就应该可以正常工作。

最佳实践是首先尝试将所做的更改合并到项目中。

如果那不是一个选择，我们只是

• 导入他们当前的HEAD，
• 在分支中进行修改
• 从他们的树上更新你的树
• 合并并重新分支

第3步和第4步对于保持分叉保持最新状态很重要。这需要大量工作，具体取决于项目的活动和保持最新状态的重要性。如果非常重要，我会每周至少更新和合并一次。

我们可能希望将其svn树导入git中，以使合并变得容易，这是我们最常做的事情

我们是否曾与项目负责人谈过？我们所做的更改是否具有一般意义，或者是否非常符合需求？如果我们无法将所需的工作纳入主项目，则可以肯定会分支他们的树，只需继续合并即可。

我们也可以研究GIT之类的功能(它可以与原始svn进行交互)以接受部分合并/补丁。分歧越远，这个问题就越多。我们当然可以使用svn和优秀的编辑器来做到这一点，但是使用更灵活的工具可以使生活更轻松。

我认为将工作移到上游是最安全的方法，因为我们可以免费获得所有错误修复，并且在上游进行的更改不会破坏工作，因为其他贡献者也必须尊重"功能"，因为他们都是项目的一等公民。如果这不是一个可行的选择，那么我要说的是git及其subversion桥，因为它已经具有很多对分叉有用的功能，无论如何，这是在git中做事的自然方法一种不同回购的叉子。

这是Visko建议的一种变体，相反的假设是我们将花费大部分时间进行自己的更改，并且仅偶尔集成原始源项目的新版本。 (使用下面的Subversion词汇表。)

• 创建项目，将原始源提交为主干。标签。
• 在进行本地更改时，根据需要使用分支，合并回主干以进行发布等。
• 通过分支文件加载(hack)源；
• 将主干合并到分支中(因为这可能需要一些时间，并且我们不想破坏主干)；
• 然后将分支合并回主干。标签。

这就是我脑子里为自己使用而设计的过程。希望收到反馈。