请教一条 git 命令, 如何通过 tag 拉取仓库及仓库下所有子模块的代码,同时每个子模块的 tag 不同
retrocode · 2022-05-30 14:39:16 +08:00 · 1096 次点击这是一个创建于 901 天前的主题，其中的信息可能已经有所发展或是发生改变。
之前一直是使用的一整个 git 仓库开发, 最近项目分仓库, 在自动化的时候遇到了问题, 子模块的 tag 是不同团队维护的, 发包是 Jenkins 自动化, 不知道怎么配 git 命令了
我之前对子模块也不熟, 目前还在熟悉阶段, 所以想请教下是否可以实现单 git 命令 拉取代码的同时, 可以给每个子模块指定分支和 tag, 例如
git pull origin master -submodule1 tag1 -submodule2 tag2 ....
我查询了下相关的文章, 各种方法 只能拉取统一 tag 的代码, 或者人工拉取对应的子模块的代码, 应该如何配置才能做到这一点
补充:
当前团队使用的是 Jenkins 发包, 但是我没有在配置中找地类似需求的配置, 有懂哥方便指导下吗
 |
1
lyc575757 2022-05-30 14:51:26 +08:00
搜了一下 好像是要在.gitmodules 文件里 手动配置子模块的 branch
|
|
2
lyc575757 2022-05-30 14:51:45 +08:00
|
 |
3
retrocode OP @lyc575757 #2 是的,指定分支这点现在是 OK 的, 问题出在服务器发版, 每次发包需要定版, 我们目前是通过 tag 1.0.0 来指定对应版本的,
发包时会有类似: ``` git update app 1.2.3 -submodules1 0.0.1 -submodules2 1.0.1 -submodules3 2.4.8 ..... ``` 这样发包的需求, 模块由不同的团队维护, 我们的想法是每次发包的时候,可单独指定每个子模块的 tag 版本号 但是查了一圈还是搞不懂如何配置子模块实现这样的需求 |
 |
4
lixile 2022-05-30 15:05:37 +08:00
主仓本身就记录了 submodule 的每个对应的 commit id ，需要指定子仓 tag 才是违背集成直觉的事情。
你在主仓 git 仓库点进各个子仓，你会发现记录的就是对应的 commit id |
|
5
lixile 2022-05-30 15:07:59 +08:00
真正发版发包的时候，除了各个子仓团队负责 push 代码和 tag 到子仓外，还需要在总仓将对应 submodule 也 checkout 到需要的 tag 上，并提交到对应分值（无论是 mr 还是 push ）
对于集成侧来说 他需要且仅需要主仓分支、tag 、commi id 即可出包，不关注也不想关注子仓对应关系。 因为本身主仓的信息已经记录了各个子仓的 commit 状态。 |
|
6
retrocode OP @lixile #4 这个之前我考虑过通过主仓库做版本控制, 被领导否了, 主要考虑到可视化操作, 可以针对单个模块做版本控制发包, 在 Jenkins 界面内直接针对模块版本做选择,
类似 app.mod1.mod2.mod3.mod4.mod5.... 这种版本一般人看不懂也记不住的 多选的话后续增加模块也更为方便, 针对每个模块做选择就可以了, 不需要另外配置版本号 |
|
7
retrocode OP @lixile #5 对对对, 我原来就是想这样的, 但是因为每次需要人工 git 对应版本在提交, 直接被否了, 所以想把通过 tag 获取对应子模块版本这一步搬运到 Jenkins 上, 然后发现 Jenkins 没有类似的配置, 查到的文章都是所有模块使用同一个 tag(foreach 轮训打的), 或者直接拉取 master 最新, 这和我们的预期不符
|
|
8
lixile 2022-05-30 15:23:48 +08:00
@retrocode
业界应该只有 git submodule 和 google repo 两个常见方案，思路几乎是一致的，无非是工具不同罢了。 git submodule 与 git 集合工作的更好一点。 指定多个 submodule 实际上是不现实，无法保证所有开发人员、devops 能清楚的了解子仓之间的对应关系，只会关心自己的一亩三分地和强关联的兄弟模块。 除非对 tag 、branch 命名，创建，保护都有很号的约定和实践（但是实际上几乎是不可能存在完全遵守约定的情况） 可视化一般是反向的，即出包后给出对应 submodule 对应的 tag 的可视化以及对应历史版本更替之类的。 但是有例外情况，就是所有 submodule 都是解耦独立，无任何版本关联，可以做成你这个样子，只不过实现上也会比较搓，而且如果是完全独立，又会变成制品仓形式进行组合，无需使用 git submodule 了（矛盾.jpg ）。 |
|
9
retrocode OP @lixile #8 难搞哦, 解耦这个目前的架构设计的应该是没问题的, 每个模块现在对应的是不同的业务流程, 之前是单仓库模式, 定期发版, 如果某一个模块出了问题,想回退很难,同时还会影响到其他团队的进度, 所以才设计成这样的,
请问下你对 Jenkins 熟吗, 源码管理的配置可以直接改成 shell 模式吗?我干脆直接写个脚本手动进对应目录 git 算求了,好烦好烦 |
|
10
lixile 2022-05-30 15:50:09 +08:00
解耦的话 不是就应该单仓发布 单仓回滚吗。为什么会回退困难，回退困难说明就是有耦合的地方。。需要版本关联。
源码配置模块是做不到的，构建模块里单独进目录 checkout 吧。。 |
Select Language