每个人如何管理工作场所的开源集成？例如，根据您的工作场所需求进行更改，然后对开源项目进行更改，然后通过jar将其合并到主代码行中。如何最好地集成新版本的开源项目，无缝地应用所有本地更改（最小的麻烦）？ SVN具有Vendor branches概念/实践，但是如果源控制系统是完全不同的呢？
答案 0 :(得分：2)
开源项目喜欢贡献。当您对开源软件进行增强时，请以通用而非破坏性的方式进行。让您的开发人员参与支持该软件的社区，并将这些更改贡献给项目。
假设您使用的是版本1.1.2，其中包含自定义功能a，b和c。如果您遵循此建议，当项目发布版本1.2.0时，您可以按原样采用它，因为主要分发中包含功能a，b和c。
成功并蓬勃发展的开源项目使用此模型。没有以这种方式获得捐款的项目通常根本无法生存。因此，您贡献的动机是2倍：
答案 1 :(得分：0)
对于这种事情你有几层质量保证。
开源资格。
您必须测试操作系统组件以确保它们确实有效。大多数情况下，这涉及运行随组件提供的测试。
但是，您可能需要特定功能或API或其他任何功能。您必须进行一项测试，该测试只是确定该组件的功能符合您的预期。
开发集成测试。
使用开源组件的开发人员在需要新版本的特定新功能时会进行集成测试。
如果操作系统库已升级，则您没有“义务”升级任何内容。毕竟，你不是在支付费用。你有来源。没有理由“自动”升级您的OS组件副本。
生产集成测试。
升级开源组件时，必须对应用程序套件进行集成测试。如果这样做，并且它投入生产，那么所有开发人员必须进行相同的升级。全面而已。
配置管理非常简单。整个原始发行版必须在您的存储库中保存 - 未经修改 - 并且必须作为应用程序的一部分进行分发 - 未经修改。
每个版本的开源发行版都是独立的。您必须保留您正在使用的每个版本。而且你必须将它们分开，以便你可以分辨哪个是哪个。
/opt/some-package/some-package-1.1/
/opt/some-package/some-package-1.2/
etc.
每个开发人员都应该进行适当的安装。同样，集成测试人员应该进行适当的安装。另外，一旦通过集成测试，生产必须安装OS包。
是的，它将软件包的一个版本放在多个位置。
是的，您必须弄清楚如何绝对确保生产升级直接导致每个开发人员也进行升级。您需要进行某种版本号审核，以确保每个开发人员都拥有正确的操作系统组件集。