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