我们有一个内部项目,例如,一个身份验证后端。这个后端的代码完全是为我们公司的需要定制的。但是,我们正在将我们的项目作为开源项目发布。为此,我们创建了一个新的身份验证后端,它使用标准和开放的软件。所以我们可以用新的后端公开发布,并为我们保留另一个。
现在的问题:
我们希望拥有没有自定义内部代码的公共 git 存储库。如何分离公共/私有代码而不冒最终导致两个项目相互偏离的风险?
很多选择在我们看来都有一些利弊,所以我们来这里看看是否有人已经遇到这种情况或有什么建议?
我们有一个内部项目,例如,一个身份验证后端。这个后端的代码完全是为我们公司的需要定制的。但是,我们正在将我们的项目作为开源项目发布。为此,我们创建了一个新的身份验证后端,它使用标准和开放的软件。所以我们可以用新的后端公开发布,并为我们保留另一个。
现在的问题:
我们希望拥有没有自定义内部代码的公共 git 存储库。如何分离公共/私有代码而不冒最终导致两个项目相互偏离的风险?
很多选择在我们看来都有一些利弊,所以我们来这里看看是否有人已经遇到这种情况或有什么建议?
单方面确保关于开源项目未来进程的任何事情都是徒劳的。你可能施加的任何控制都只会被社区规避(例如通过分叉),如果它们最终限制了人们想要采取的方向。
所以在某种程度上,保持一致性意味着你必须在内部承诺让你的内部版本与 OSS 版本保持一致。(这样的承诺不必是绝对的……只是,如果公共变化超出了你愿意跟上的范围,那么项目就会出现分歧。)
也就是说,您可以做一些可能会阻止导致公共和私人版本出现分歧的更改的事情。对我来说,这意味着两件事:
1) 您不希望更改身份验证后端和主项目之间的接口,以便在公共和私有身份验证后端之间进行交换。
虽然看起来有点单薄,但一步是将 auth 后端与主项目分开发布。每个都可以有自己的 git 存储库,假设您在构建工具中使用依赖管理器,则后端可以列为主项目的依赖。然后,对主项目进行修改的人甚至可能不会下载身份验证后端的源代码;无论如何,要更改两者之间的接口,他们必须对两个公共项目进行协调更改。它降低了它偶然发生的可能性。
2)您还想确保无论发生什么更改,您都可以在项目的公共版本和本地版本之间来回传递它们。
通过为“什么是相同的”(主要项目)保留一个存储库和为“什么不同”(身份验证后端)保留一个单独的存储库(公共和私有)来再次帮助实现这一点。