最近遇到一个关于 jar 包管理的疑问。记录下，说不定哪天遇到最佳实践。
有一个工程 X，对应一个 jar 包，用于做接口定义，当前版本为 1.0.0。
佳佳、包包两人，分别要在工程 X 中定义新方法 A 和 B。
并且在项目 P 中实现方法。
佳佳定义了新的方法 A，将 jar 包版本升级到 1.0.1-SNAPSHOT，deploy 到仓库。
包包也定义了新的方法 B，也将 jar 包版本升级到 1.0.1-SNAPSHOT，deploy 到了仓库。
佳佳在某次重启的时候，发现 IDE 提示没有实现方法 B。
于是，佳佳和包包准备协商一种 jar 包管理的方法。
考虑以下几点：
两人不能共用一个版本的 jar 包。佳佳的程序只需要关注方法 A，而不可能实现包包需要实现的 method B。
考虑到两人的代码将在开发环境共存一段时间，又需要将两人的方法定义统一在一个 jar 包内，部署到仓库，供开发环境的项目 P 使用。
考虑到上线顺序不定，不能随意将 jar 包升级到某个正式版。
暂时想到可行的办法：
在本地，大家有自个的环境。不需要考虑代码层面的冲突，只需要关注 jar 包 SNAPSHOT 版本是否冲突。因为 SNAPSHOT 是可变的。当前包版本为 1.0.0 时，佳佳打包版本为 1.0.1.jiajia-SNAPSHOT；包包则打包为 1.0.1.baobao-SNAPSHOT。
涉及到联调和实现，可直接当该 jar 包提供给使用方。因为佳佳的联调方只需关注 1.0.1.jiajia-SNAPSHOT 中提供的方法 A。
佳佳首先在项目 P 中实现了方法 A ，并将代码推到开发 dev 分支，引用的 jar 包版本为 1.0.1.jiajia-SNAPSHOT。
包包在项目 P 中引用 1.0.1.jiajia-SNAPSHOT，当需要将项目 P 的代码推到 dev 分支时，发现冲突。从 jar 包版本得知，佳佳也在同时开发。
此时，包包在工程 X 中新建解决冲突分支，解决冲突，新打一个包为 1.0.1.conflict-SNAPSHOT，并在项目 P 中引用该包。顺利部署到开发环境。
涉及到冲突解决，两人在工程 X 中定义完新方法后，需要将对应的分支推到主仓库让对方看到。并使用明显的分支名称，方便对方解决冲突。
需要上线时候，假设包包先上线。拉取工程 X master 分支的代码，防止佳佳已经上线，得知最新版本没变，则在工程 X 中打包 1.0.1，项目 P 引用 1.0.1 顺利上线。并将代码合并到工程 X 的 master 分支。
佳佳上线时，首先拉取工程 X 的 master 分支，发现1.0.1被占用，则使用最新版本1.0.2。
