我们有一个类似于Best Practice for Git Repositories with multiple projects in traditional n-tier design的结构，包含以下存储库：
Shared
ProjA
ProjB
ProjA和ProjB由不同的2-3人团队开发，使用{有权对Shared做出贡献。
我们想到了一个不需要子树或子模块的简单模型，因为我们读到了很多关于那些的恐慌2.您能否回顾并告诉我们这样的事情是否有效？
Proj和Shared每个都在一个单独的仓库中，遵循gitflow模型develop分支中的最新版本构建
<{1}}的{li> release.sh将合并到Proj和master的{{1}}，在两者上创建一个标记，Jenkins将从中构建和部署Proj。
这可以吗？请记住，我们只有8个人，我们只是迁移到git中，所以我们希望尽可能简单地保存东西，所以如果我们能够避免子模块和子树的学习曲线，我们会更高兴。或者我们会吗？
答案 0 :(得分：1)
如果ProjA和ProjB保留在某个地方（在版本化文本文件中或作为git notes）Shared的确切引用，它可以正常工作。
构建调度程序背后的想法是可重复性：这样的工具需要能够重现用于给定构建的确切配置（即SHA1引用列表）。
这允许稍后重新访问构建。
答案 1 :(得分：1)
我觉得你的问题不是git结构，但项目的依赖性，例如SVN不会让你的生活更轻松。
如果你有两个项目取决于共享项目，我相信你不应该逃避指定。
如果B组中的某人在项目A发布之前更改了共享，该怎么办？您可能会对项目A进行不必要的更改。
为了克服你应该使用项目版本控制，这里git子模块可以解决，子模块是项目X和共享的特定时间点之间的依赖关系。
git子模块的替代方法是工件版本感知依赖项，在大多数（所有？）现代语言中，您可以这样做。 例如，在Java中，您将使用maven / ivy / gradle来定义项目依赖项。 （您需要将 shared 上传到某些工件库）
我不会说替代方法比git子模块更简单，但是当项目的结构越来越复杂，许多工件依赖于彼此时，它是（必须？）的方式。