0

问题：我们为银行开发系统。这些系统（理论上）是高度安全的，并且几乎总是受到相当严格的 NDA 的保护。因此，虽然各个项目之间有一些共享代码，但其中很多是完全独立的。也就是说，如果一个项目的代码或文档“渗入”到另一个客户拥有的另一个项目中，那将是灾难性的。两个客户要求我们将代码推送到他们的仓库（我们的合同要求的一部分），加剧了这个问题。

迄今为止，我们只是为每个客户使用了一个完全独立的 repo。当然，这意味着在某些情况下，我们有相同代码模块的重复；如果在一个存储库中进行更新而不分发给其他存储库，则更改/修复将不可避免地丢失。如果我们只需要维护一份此类文件的副本会更好。

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

显然，一等奖将是拥有一个单一的存储库，但只有某些目录或文件被上传到特定的远程存储库。虽然我很欣赏这可以在一定程度上通过使用.gitignore和每个客户端的单独分支来实现，但我担心手指问题（如果有人不恰当地编辑 .gitignore 文件）可能会导致我正在尝试的事情避免。

我们几乎所有的开发平台都是基于 Linux 的，但一个遗留系统的开发环境只能在 Windows XP 上运行，并且由于某种原因它不能在 Wine 下运行（我怀疑与 Java 运行时有关，但这是另一天的故事） .

我考虑过使用 rsync 或符号链接来共享公共文件，但它看起来很俗气，如果某些白痴更改源模块旧版本的文件日期，也可能会造成麻烦。目前，我们有太多的个人存储库和重复的模块以满足我的喜好，我可以看到它在轨道上造成了麻烦。我认为这一定是一个相当普遍的问题，而且我确信有人已经以一种稳定的、独立于平台的方式处理了它，并且不假设开发人员在提交时永远不会出错。

4

3 回答 3

3

鉴于此，我希望：

当然，这意味着在某些情况下，我们有相同代码模块的重复；如果在一个存储库中进行更新而不分发给其他存储库，则更改/修复将不可避免地丢失。如果我们只需要维护一份此类文件的副本会更好。

解决方案是维护通用存储库（不绑定到任何客户端）来构建库组件。这样，您将构建不同版本的库（适当的版本化），并且客户端代码的不同版本将使用这些库，而不是导入实际代码。

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

显然，一等奖是拥有一个单一的存储库，但只有某些目录或文件被上传到特定的远程存储库

由于上述原因，我认为这不是可扩展的或实用的。我认为您最好能够对您的开发进行沙箱化并使生成的二进制文件可用于下游消费。如果我签出一个新的客户端存储库，我不必重新构建所有依赖代码，而只需下载工件（如果你的存储库支持，还可能下载源代码）

存在各种分发二进制部署的解决方案（例如，在 Java 世界中，请查看Sonatype 的 Nexus及其与 Maven 构建工具的集成。Nexus/Maven 支持与二进制一起下载打包的源代码）。

于 2013-05-15T16:51:00.647 回答
0

您是否考虑过为公共模块和代码创建一个存储库并将其克隆到每个项目存储库中？这样，您可以为每个项目使用相同的核心代码库，同时为您的客户保持独立。

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

于 2013-05-15T16:54:40.873 回答
0

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

于 2013-05-15T16:54:45.410 回答