git - 一个存储库,几个客户端,最好没有子模块

时间:2013-05-15 16:47:18

标签: git

问题: 我们为银行开发系统。这些系统(理论上)非常安全,几乎总是受到非常激烈的NDA的保护。因此,虽然各个项目之间存在一些共享代码,但很多项目完全是分开的。也就是说,如果一个项目的代码或文档“流失”到另一个项目所拥有的另一个项目,那将是灾难性的。两个客户要求我们将代码推送到他们的仓库(我们的合同要求的一部分),这个问题更加严重。

到目前为止,我们只是为每个客户使用了一个完全独立的回购。当然这意味着在某些情况下我们有相同代码模块的副本;如果在一个仓库中进行更新而不分发给其他仓库,则更改/修复将不可避免地丢失。如果我们只需要维护此类文件的一个副本,那就更好了。

另一种方法当然是为每个客户端使用一个分支,但我发现在分支之间合并的开销是不可支持的。此外,我已经看过git子模块了,但是,这些似乎过于充满了危险,因为粗心的提交可能构成项目之间的“中国墙”,并且合并似乎比仅仅通过分叉更复杂该项目(见http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/)。我不喜欢实现开发人员必须记住特定过程的系统,因为当事情匆忙完成时,错误是不可避免的。

显然,一等奖将是一个单个存储库,但只有某些目录或文件上传到特定的远程存储库。虽然我很欣赏可以在某种程度上通过使用 .gitignore 和每个客户端的单独分支来完成,但我担心手指麻烦(如果有人编辑了。 gitignore文件不恰当),可能导致我试图避免的事情。

我们几乎所有的开发平台都是基于Linux的,但是一个遗留系统的开发环境只能在Windows XP上运行,并且由于某些原因它不会在Wine下运行(链接到我怀疑的Java运行时但这是一个故事)另一天)。

我已经考虑使用rsync或符号链接来共享公共文件,但它看起来很俗气,如果某个白痴更改旧版本源模块上的文件日期,也可能会造成麻烦。目前我们有太多的个人存储库和我喜欢的重复模块,我可以看到它导致故障。我认为必须是一个相当普遍的问题,我确信有人已经以稳定,独立于平台的方式处理它,并不认为开发人员永远不会犯错误提交。

3 个答案:

答案 0 :(得分:3)

我希望如此:

  

当然这意味着在某些情况下我们会有相同的副本   代码模块;如果进行更新,更改/修复将不可避免地丢失   在一个回购中,而不是分发给其他人。会好得多   如果我们只需要保留这些文件的一份副本。

解决方案是维护公共存储库(不依赖于任何客户端)来构建库组件。这样,您可以构建不同版本的库(适当版本化),不同版本的客户端代码将使用这些库,而不是导入实际代码。

我通常会存储这些库的不同(成功)版本,并在客户端的代码库中指定要使用的库版本。库项目将定义库测试等,并通过更改客户端项目中的版本号,您可以指定使用哪个版本的库(例如,带有修复的新版本)。

  

显然,一等奖将是拥有一个单一的存储库,但在哪里   只有某些目录或文件上传到特定的遥控器   回购

由于上述原因,我认为这不是可扩展的或实用的。我认为您最好能够对您的开发进行沙盒化并使得生成的二进制文件可用于下游消费。如果我签出新的客户端存储库,我不必重建所有相关代码,只需下载工件(如果您的存储库支持,也可以下载源代码)

存在用于分发二进制部署的各种解决方案(例如,在Java世界中,检查Sonatype's Nexus及其与Maven buildtool的集成.Nexus / Maven支持与二进制文件一起下载打包的源代码)。

答案 1 :(得分:0)

您是否考虑过为常用模块和代码创建存储库并将其克隆到每个项目存储库中?这样,您可以为每个项目使用相同的核心代码库,同时仍然将它们与客户分开。

如果您决定,如果因任何原因在更新期间发生冲突,您甚至可以使用核心模块的不同分支。

答案 2 :(得分:0)

您需要的是要意识到您拥有基本上是库的组件。此库仅包含对项目完全独立且中立的部分,但需要启用某些功能。这样的库作为子模块或树添加,并独立维护和开发。两个客户项目的开发人员都不会犯错误,因为他们只知道让这个库保持最新以及如何使用它,但永远不要直接更改它。他们可能会重新实现为他们定制的特定版本,但这永远不会被提交,因为它保留在您的客户端项目中。