非常详细的trunk-based分支管理流程配置及使用。
目前业界主流的版本管理流程是Gitflow 和 trunk-based。
Gitflow流行的比较早。但是目前的流行度要低于 trunk-based模式工作流。trunk-based模式被誉为是现代化持续集成的最佳实践。
他俩的核心区别是，Gitflow是一个更严格的流程，只需要特性的管理员来批准代码可以合入主干。这样可以保证主干分支的代码质量。
而trunk-based流程相对而言更开放，所有开发者都有权限合入主干，以此来达到团队快速迭代功能的目标。
trunk-based流程
所有研发人员直接在trunk上提交代码。
对外发布产品的时候需要从trunk上拉取release分支（比如1.1.x和1.2.x），并基于release分支来发布(比如1.1.0和1.1.1)。
release分支中出现的bug或者需要性能优化时，则需要在trunk上完成，并通过cherry-pick的方式在trunk中挑选对应的commits合并到release分支，此时的小版本号从1.1.0变成1.1.1。
对外发布新功能时，需要基于trunk分支，重新拉取release分支，版本号从1.1.x变成1.2.x，同时1.1.x的release分支将被废弃。
在trunk分支上，每个commit之间的提交间隔很短，通常在一天之内提交好几次，甚至更多次。
trunk-based vs. Gitflow：
Trunk-based流程的特点在于其名字，基于主干进行开
