git - 为微服务存储子模块，但仍然使用 fork

Question

我在这里被难住了。其中很多已经到位，只是我无法弄清楚的包装。

我们有一个微服务架构，有许多独立的存储库。我们使用 Docker 和 Docker Compose 构建和运行开发环境，效果非常好。

我的问题是如何打包存储库的主要集合。因此，如果我的文件夹结构如下:

\
    service1
        .git
        Dockerfile
    service2 
        .git
        Dockerfile
    service3
        .git
        Dockerfile
    docker-compose.yml
    README.md

...其中 service1、service2、service3 是各自的 git 存储库。

我的第一个想法是使用 git 子模块，这会 起作用，但是由于持续集成限制和代码审查，我们实现了要求开发人员 fork 存储库而不是离开主存储库的政策。我对使用 git 子模块一点也不兴奋，甚至在我想到这个警告之前，所以更喜欢替代解决方案。

目前我只能考虑编写脚本来存储存储库列表；对每个运行一个查询，看看登录的开发人员是否有每个的分支，如果没有，则创建一个，然后 pull 入主文件夹；然后启动 docker-compose。不过，这似乎是一个糟糕的解决方案，足以让我可能只需要编写文档来告诉开发人员如何手动执行此过程...

想法??

感谢您的宝贵时间:)

Answer 1

我在工作流方面遇到过类似的问题(除了我没有使用 fork )。最终我的要求归结为一件事:

• 作为一名开发人员，我想运行 1 个命令 project bootstrap 来引导我的环境

---

我建议做一些事情来优化工作流程，这对我来说效果非常好:

• 在 JSON 文件中存储服务列表，其中每个服务都有“url”、“fork_url”、“name”和 docker-compose 了解如何处理此服务所需的其他通用属性。似乎您团队中的每个团队成员都会有 fork url 或 base repo url

• 构建一个命令行应用程序(有许多可用的选项 - 取决于您选择的语言，对于 Ruby，它是 gem Thor，对于 Go，它是包 Cobra，等等)。通常构建一个简单的命令行应用程序结构和前几个命令只需要几个小时，但这种类型的自动化每天都会为您节省时间，并且您将为扩展命令行打下基础随着您的需求增加，该应用程序被证明是可行和有用的。您还将拥有一个统一的界面来为所有团队成员配置您的环境，然后由团队负责维护它。

• 构建一个 project bootstrap 命令来配置您的环境。例如，它将:
  • 检查 JSON 文件中的服务列表:
    • 如果不存在就 fork
    • 克隆你的代码库
    • 向您的存储库添加另一个 Remote ，它将代表 fork(除了 origin)
    • 将从指定目录中的模板生成docker-compose.yml