现在项目中使用 protobuf 作为消息体，多个团队开发多个服务，有些是 go 有些是 java ，目前的.proto 文件在每个仓库里都有一份，维护起来很痛苦，有没有什么好的方案呢，github 的 submodules 能解决这个问题吗
20 条回复 • 2024-10-15 10:20:20 +08:00
 |
1
FabricPath 21 天前
对新增的 API 或者字段没有需求的情况下，为啥要更新 proto...
如果整个经常需要所有引用方更新 proto ，那先问一下改 proto 的人为什么不能做到前后兼容。 所以，直接复制一份也没啥问题，你现在的痛苦不是“复制 proto”带来的 |
 |
2
erquren 21 天前  1
.proto 应该是一个单独的仓库啊，大家拉了生成自己语言的代码
|
 |
3
dylanqqt 21 天前
每个服务应该要有一个独立的 proto 仓库。比如服务 1 有一个 proto1 的仓库，专门存放生成好的 pb 代码，如果服务 2 需要调用服务 1 就 go get proto1 就可以了。这样子所有的服务业务仓库都不会有 proto 代码。
|
 |
4
litchinn OP @FabricPath 开发阶段我觉得哪怕觉得某个字段名字不合适改个名字这种都很正常吧，release 后才会考虑版本前后兼容问题
|
 |
8
aihimmel 21 天前 via Android 1
git submodule
|
 |
9
JimLee0921 21 天前
你的头像也是用的 notionavatarmaker 生成嘛？哈哈哈
|
 |
10
csys 21 天前 via Android 1
我所知道的绝大多数工程实践都是用的 git submodule ，可以参考一些多语言的开源项目，比如 temporal
|
 |
11
mb4555 21 天前
写个脚本 原始文件一个目录 不同语言的分各自的目录
|
 |
16
so1n 21 天前
全部放同一个仓库，这个仓库使用 make 命令来生成代码，不同语言的代码放在不同的目录
|
 |
17
Charlie17Li 21 天前 via iPhone
@tuolee666 牛的好用
|
 |
18
povsister 21 天前
单独一个仓库，开发 proto 先行，聊需求聊技术方案都拿着 proto 来说话。
接入使用云端 buf package 专门按 commit hash/分支托管产物，或者 java 这种可以本地 submodule+build 。 |
 |
19
ericFork 21 天前
一个仓库生成各个语言用的包，然后下游各语言的服务用依赖包的方式引入
|
 |
20
sujin190 21 天前 via Android 1
既然如此为什么不在放 proto 文件的项目直接生成并发布各个语言的 sdk 包呢，私仓加自动发布就好了啊
|
 |
21
flmn 20 天前
git submodule 已经是一个好方案了，不必东奔西走了。
|
Select Language