没有子模块/子树的多个存储库的简单gitflow模型？

Question

我们有一个类似于Best Practice for Git Repositories with multiple projects in traditional n-tier design的结构，具有以下存储库：

  Shared
  ProjA
  ProjB

在这里，ProjA和ProjB是由2-3个人组成的单独团队开发的，他们使用Shared，有时还对Shared做出贡献。

我们想到了一个简单的模型，它不需要子树或子模块，因为我们读到了那么多关于这2的恐惧。你能回顾一下，让我们知道这样的事情是否有效吗？

• 每个Proj和Shared都生活在一个单独的回购中，遵循gitflow模型
• Jenkins将使用所有3个repos的develop分支的最新版本进行构建。
• release.sh of a Proj将合并为Proj和Shared的master，在两者上创建一个标记，Jenkins将从master构建和部署。

这个能行吗？记住，我们只有8个人，我们只是在迁移到git，所以我们希望尽可能地保持简单，这样如果我们能够避免子模块和子树的学习曲线，我们就会更快乐。或者我们会吗？

Answer 1

如果ProjA和ProjB在某个地方(无论是在版本化的文本文件中还是以git notes的形式)保存Shared的确切引用，它就可以工作。

构建调度器背后的思想是reproducibility：，这种工具需要能够重现用于给定构建的确切配置(即SHA1引用列表)。

允许稍后重新访问构建。

Answer 2

我觉得您的问题不是git结构，而是项目的依赖关系，例如SVN不会使您的生活变得更容易。

如果您有两个项目依赖于一个共享项目，我相信您不应该逃避指定该项目。

如果B组的人在项目A发布之前进行了共享更改，该怎么办？您可能会在项目A中得到不必要的更改。

为了克服您应该使用项目版本控制的问题，在这里git子模块来拯救您，子模块是项目X与共享特定时间点之间的依赖关系。

git子模块的另一种选择是工件版本感知的依赖关系，在大多数情况下(全部？)现代语言你可以做到。例如，在Java中，您可以使用maven/ivy/gradle来定义项目依赖项。(您需要将shared上传到某些工件存储库)

我不会说替代方案比git子模块更简单，但是它是(必须？)当项目的结构变得更加复杂时，当许多工件相互依赖时，要走的路很远。