神策原来的前端项目都是多模块分repo的代码组织方式，导致开发比较繁琐，大量的时间花在了切分支，提mr，打tag，改版本号这些操作上，还时时容易出错，于是最近利用git submodule 把SPS的多个模块聚合在一起开发，并加入了一些批量脚本尽可能让大家能感受到和 monorepo 一样的开发体验。

http://gitlab.internal.sensorsdata.cn/sps/components/sps_submodule

这个仓库是一个利用git submodule聚合多个子模块的仓库，它的作用是帮助提高 SPS 的开发体验和效率，目标是尽量有 monorepo 一样的开发效率。

SPS 一共有12个子模块，目前加入常用的 5 个子仓库，通俗的话就是加入了五个仓库指针，每个子仓库的任何改动和提交都需要提到原有仓库，不影响之前的提交记录。

快速开始

初始化和更新所有的子模块：

git clone git@gitlab.sensorsdata.cn:sps/components/sps_submodule.gitgit submodule update --init --recursiveyarn

这样就可以获取所有子模块的最新代码。以后你只在这里就可以维护所有模块了。避免了多次切换仓库，修改，提交，提mr的痛苦。

什么是git submodule

git submodule是一种在一个git仓库中引用另一个git仓库的方法。它可以让你在一个项目中使用另一个项目的代码，同时保持两个项目的提交历史分开。git submodule只跟踪特定的提交，不跟踪分支或标签，也不会自动更新。

为什么不用 monorepo

1. 相互依赖性管理困难：老旧项目中的子模块可能已经有相互依赖关系，并且它们之间的版本和依赖关系可能比较复杂。将这些子模块合并到一个 monorepo 中会增加相互依赖性管理的复杂度，可能需要重新调整和解决依赖关系。

2. 维护历史提交记录的需求：利用 git submodule，每个子模块都保留了自己的提交历史记录，这对于追溯和管理每个子模块的变更非常重要。如果使用 monorepo 的方式，子模块的提交历史记录将被混合在一起，导致难以区分和管理各个子模块的变更历史。

3. 额外的测试成本： 老项目改成 monorepo 是有风险的特别是有些依赖关系的改动，这种改动是需要额外的测试成本。SPS已经进入维护阶段，git submodule 这种侵入性小的方案反而优势巨大。

强烈建议

如果你经常需要对所有子模块执行相同的git命令，比如切换分支，提交代码等，你可以使用git submodule foreach命令来批量操作。为了方便起见，你可以给这个命令加一个别名，比如：

git config alias.sfe 'submodule foreach'

这样你就可以用git sfe来代替git submodule foreach了。

或者加入 .zshrc 中

alias gits="git submodule foreach"

可以用 gits代替 git submodule foreach

如何利用git submodule批量切分支，提交代码

如果你想对所有子模块执行相同的git命令，你可以使用git submodule foreach命令来批量操作。比如，如果你想切换到test/1.8.1分支，你可以这样做：

gits git checkout test/1.8.1

如果你想提交所有子模块的修改，你可以这样做：

gits git add .gits git commit -m "some message"

注意，这些命令只会影响本地的子模块，如果你想推送到远程仓库，你还需要执行：

gits git push origin HEAD

或者：

git push --recurse-submodules=on-demand

如何快速批量从tag切出对应版本分支开发

产品意义上的版本和每个模块的版本是不一致的，我们日常的开发就是每个模块去看，去tag列表上找最新的tag然后再到本地从tag切出分支，重复进行此操作，十分繁琐还容易出错。这里也准备了一个脚本和一个产品版本和模块版本的对应关系的JSON。

{  "产品版本号": {    "子模块名称1": "子模块版本1",    "子模块名称2": "子模块版本2",    ...  },  ...}

node ./newBranch.js 产品版本号

选择需要切出的模块。

这样你就可以开始在一个聚合项目开发了。

如何快速批量提交 mr

目前写一个提交mr的脚本，可以批量给每个仓库提交mr。

node mr.js release/1.8.2  feature:新增workload功能点

1. 是否为所有子模块提交合并请求

2. 或者选择部分子仓库提交

脚本会自动判断每个子仓库当前分支和目标分支是有差异，没有差异则跳过此模块

最后会为你选择的每个模块创建MR，复制链接放到群里就可以开始review了。

其它设置(可选)：在 mr.js 中，可以修改以下配置

// 设置变量const SUBMODULES_MR_DESCRIPTION = "mr 描述"; // 批量mr的描述const SUBMODULES_MR_ASSIGNEE_ID = "686";   // review 同学的idconst SUBMODULES_MR_LABELS = "submodule";   // 设置 mr labelconst PRIVATE_KEY = "glpat-****************"; // gitlab api key

后续计划

1. ci 自动化，目前mr和测试分支推到各模块后会自动跑测试ci，还需要手动改APP中package的版本，后续可以把这一步集成一下，减少人力负担。

近期文章：

浅谈Spring框架设计原则

Early Hints让页面加载更快