对于个人开发者或者这个仓库只有你一个人在用，分支策略可以非常简单，一个主干开发分支，用于日常代码提交，需要发布版本的时候，建立一个发布分支，如果发布出现bug，则先在主干上提交，再cherry-pick到发布分支。你可能注意到了，上面的分支是带版本号的，这里用的是“语义化版本”命名规则，只包含主版本和次版本号。如果有bugfix，只需要增加tag来标识小版本变更就可以了，不需要新建分支，同时修改的范围也好控制，不至于引入主干上过多无关修改。
主干开发，分支发布策略同样适用，对于大的特性（开发周期大于一个月），建立单独的特性开发分支，开发完成后，【rebase】到主干上。特性发布后，删除特性分支。
首先按照业务分仓，保持各个仓库业务独立，使用规范化的API来做业务隔离。同时使用多仓库管理工具（google repo或者使用git submodule）来管理多仓库之间的依赖。在一个业务发布时，除了记录本业务仓库的版本信息，还需要记录依赖仓库的版本信息，google repo和git submodule都提供了类似的功能。在仓库内部依然可以使用主干开发分支发布的策略。
相关链接：
【文章不错，鼓励一下】
