![]() |
1
FabricPath 2024-10-14 16:20:41 +08:00
对新增的 API 或者字段没有需求的情况下,为啥要更新 proto...
如果整个经常需要所有引用方更新 proto ,那先问一下改 proto 的人为什么不能做到前后兼容。 所以,直接复制一份也没啥问题,你现在的痛苦不是“复制 proto”带来的 |
![]() |
2
erquren 2024-10-14 16:21:22 +08:00 ![]() .proto 应该是一个单独的仓库啊,大家拉了生成自己语言的代码
|
3
Pdk5a8759cbeD6CH 2024-10-14 16:26:38 +08:00
每个服务应该要有一个独立的 proto 仓库。比如服务 1 有一个 proto1 的仓库,专门存放生成好的 pb 代码,如果服务 2 需要调用服务 1 就 go get proto1 就可以了。这样子所有的服务业务仓库都不会有 proto 代码。
|
![]() |
4
litchinn OP @FabricPath 开发阶段我觉得哪怕觉得某个字段名字不合适改个名字这种都很正常吧,release 后才会考虑版本前后兼容问题
|
![]() |
5
litchinn OP @erquren 现在是想准备用一个仓库放,但是还得拉下来挪进项目里再生成代码感觉有点麻烦,总之就是既想使用便捷又想更改便捷
|
![]() |
6
litchinn OP @dylanqqt go 的好像可以这样,java 的应该也可以作为外部依赖引用进来,但是不知道有啥办法能同时兼容这俩语言乃至 python
|
7
Pdk5a8759cbeD6CH 2024-10-14 16:53:23 +08:00
@litchinn 如果不能兼容的话可以写个脚本推到 git 的时候同时推到 java 的依赖库,go 就直接 go get java 就从依赖库引用
|
8
aihimmel 2024-10-14 16:57:36 +08:00 via Android ![]() git submodule
|
![]() |
9
JimLee0921 2024-10-14 16:58:25 +08:00
你的头像也是用的 notionavatarmaker 生成嘛?哈哈哈
|
10
csys 2024-10-14 16:59:08 +08:00 via Android ![]() 我所知道的绝大多数工程实践都是用的 git submodule ,可以参考一些多语言的开源项目,比如 temporal
|
![]() |
11
mb4555 2024-10-14 16:59:08 +08:00
写个脚本 原始文件一个目录 不同语言的分各自的目录
|
13
concernedz 2024-10-14 17:00:37 +08:00
|
![]() |
16
so1n 2024-10-14 18:04:50 +08:00
全部放同一个仓库,这个仓库使用 make 命令来生成代码,不同语言的代码放在不同的目录
|
![]() |
17
Charlie17Li 2024-10-14 19:17:58 +08:00 via iPhone
@tuolee666 牛的好用
|
![]() |
18
povsister 2024-10-14 19:23:05 +08:00
单独一个仓库,开发 proto 先行,聊需求聊技术方案都拿着 proto 来说话。
接入使用云端 buf package 专门按 commit hash/分支托管产物,或者 java 这种可以本地 submodule+build 。 |
![]() |
19
ericFork 2024-10-14 19:23:08 +08:00
一个仓库生成各个语言用的包,然后下游各语言的服务用依赖包的方式引入
|
![]() |
20
sujin190 2024-10-14 19:35:26 +08:00 via Android ![]() 既然如此为什么不在放 proto 文件的项目直接生成并发布各个语言的 sdk 包呢,私仓加自动发布就好了啊
|
21
flmn 2024-10-15 10:20:20 +08:00
git submodule 已经是一个好方案了,不必东奔西走了。
|