如何处理多团队跨语言.proto 管理

对新增的 API 或者字段没有需求的情况下，为啥要更新 proto...
如果整个经常需要所有引用方更新 proto ，那先问一下改 proto 的人为什么不能做到前后兼容。

所以，直接复制一份也没啥问题，你现在的痛苦不是“复制 proto”带来的

.proto 应该是一个单独的仓库啊，大家拉了生成自己语言的代码

每个服务应该要有一个独立的 proto 仓库。比如服务 1 有一个 proto1 的仓库，专门存放生成好的 pb 代码，如果服务 2 需要调用服务 1 就 go get proto1 就可以了。这样子所有的服务业务仓库都不会有 proto 代码。

@FabricPath 开发阶段我觉得哪怕觉得某个字段名字不合适改个名字这种都很正常吧，release 后才会考虑版本前后兼容问题

@erquren 现在是想准备用一个仓库放，但是还得拉下来挪进项目里再生成代码感觉有点麻烦，总之就是既想使用便捷又想更改便捷

@dylanqqt go 的好像可以这样，java 的应该也可以作为外部依赖引用进来，但是不知道有啥办法能同时兼容这俩语言乃至 python

@litchinn 如果不能兼容的话可以写个脚本推到 git 的时候同时推到 java 的依赖库，go 就直接 go get java 就从依赖库引用

git submodule

你的头像也是用的 notionavatarmaker 生成嘛？哈哈哈

我所知道的绝大多数工程实践都是用的 git submodule ，可以参考一些多语言的开源项目，比如 temporal

写个脚本 原始文件一个目录 不同语言的分各自的目录

@mb4555 #11 全都放同个仓库

@tuolee666 是的，作者当时在本站宣传的 /t/804653

@aihimmel @csys 那我还是去研究下 submodule 看怎么实现

全部放同一个仓库，这个仓库使用 make 命令来生成代码，不同语言的代码放在不同的目录

@tuolee666 牛的好用

单独一个仓库，开发 proto 先行，聊需求聊技术方案都拿着 proto 来说话。
接入使用云端 buf package 专门按 commit hash/分支托管产物，或者 java 这种可以本地 submodule+build 。

一个仓库生成各个语言用的包，然后下游各语言的服务用依赖包的方式引入

既然如此为什么不在放 proto 文件的项目直接生成并发布各个语言的 sdk 包呢，私仓加自动发布就好了啊

git submodule 已经是一个好方案了，不必东奔西走了。