GRPC Protobuf管理之submodule

JamesB

使用Git Submodule方式管理proto文件，各项目直接依赖IDL文件本身，依赖源头均来自git子仓，保证依赖源的唯一性。对齐各服务间的proto文件版本。
依赖问题引发的问题是很多的，对于依赖的管理也会出现很多，例如：
子仓目录

参考Google家的库googleapis：

子仓不保存IDL文件生成的中间文件，只保存原始文件。

项目引入

• 引入子仓
  

git submodule add https://xxxx.com/xxxx/myapis子仓在引入后，不去更新，子仓会呈现固定的版本。



目录结构

更新子仓，合并上游版本变化
// 进入子仓内，运行命令
$ git fetch
$ git merge origin/master

// 也可以在主仓中，运行命令
$ git submodule update --remote myapis更多关于子仓的操作命令，参考：Git-工具-子模块，也可参考下图。
脑图分享链接：



Git-Sub子仓

proto文件

proto文件中，package、option go_package，这两个参数是我们需要注意的：
package：即别的proto文件在引用该文件后，其使用的索引前缀。
option go_package： protoc 编译时，生成的路径地址，可以用go_out设置生成的路径，使用source_relative让文件生成在相对路径中。
proto文件语法以及版本追踪工具：

• buf 推荐
  
• protolock
  
• api-linter
  

编译

由于依赖原始文件，在拉取到子仓后，或是更新到最新子仓后，proto文件都应是再次编译，故在Makefile中，build命令中，需要加入重新编译proto文件的操作，让proto文件每次都保持最新状态，防止中间版本的出现。

也可以使用例如BAZEL编译，声名依赖，指定proto文件。

实践例子

案例：kratos-layout