多项目团队的 Git 组织

Question

这是另一个 GIT 新手。

• 我想在我们的项目中使用 GIT。
• 团队不熟悉 GIT。

这些项目基本上由一些通用项目(*)和一些应用项目组成。应用程序正在使用公地，公地也可以使用其他公地。通过“使用”我的意思是他们共享源代码会很棒。或者至少一个项目可以使用一个普通项目的已编译 dll。 这是我希望我的文件夹结构的示例:

common
+-- basics
    +-- gui
    +-- utils
+-- win
    +-- gui.win
    +-- utils.win

app1
+-- win
    +-- app.win

这里的项目gui.win需要使用common > gui。 app.win 肯定需要 gui.win。

GIT

子模块

对于 GIT 存储库，我开始研究子模块。但它似乎是关于更多的静态库。开发 app.win 的人需要做大量工作才能 pull 所有其他子模块并确保拥有最新版本。

子树

对于这些，唯一的解决方案似乎涉及一些脚本来处理依赖性。因此，它增加了日常工作流程的负担。熟悉 GIT 已经足够我们日常工作的开销了。

多存储库

这个解决方案有很多优点。看起来很干净。它清楚地将工作主题等分开。但我不知道如何以这种方式处理项目之间的依赖关系。 app.win 怎么会引用(*) gui.win？

全局存储库

然后我认为唯一的解决方案是拥有一个包含所有内容的大型存储库。那现实吗？ (给出一个数量级:这棵树中的 common 应该少于 10 个项目，大约有 20 个应用程序)。 然后，我们可以为每个应用程序使用一个 main 分支(一个用于 common)，并为子项目、功能或热修复程序使用子分支。 我们会使用像“app1.v1.0”这样的标签来标记里程碑版本。

---

* 因为我在使用 VisualStudio，所以我在这里使用了一些术语。项目是一组输出库或应用程序的文件。引用是指向另一个项目的输出或对源代码的访问的链接(就像使用相同的项目有不同的解决方案)

Answer 1

你可以对任何类型的子模块使用 git submodule，它不限于静态库。例如，我的 ~/.vim 文件夹是版本化的，我安装的每个插件都有几个子模块。

我认为这是首选解决方案，因为主存储库可以记住您的项目使用的修订版本，并且您可以使用单个命令同步所有子模块。

因此，您可以让一个团队或一个人处理子模块本身作为一个项目，进行更改、提交等。当您想要包含更改时，您只需在主存储库中执行此操作，而不必为任何正在进行的版本而烦恼。