《Git团队协作》介绍了几种分支策略，结合之前在工作中用到的分支策略，简单总结下。
一、主线分支开发
主线分支开发.png
这是最基础的分支策略，有且只有一个分支——master，所有人都可以随时提交到master分支，随时可以部署发版。在项目规模小，开发者数量不多并且大家负责的工作比较独立的情况下，这样简洁的分支策略已经可以满足了。但是一旦出现问题之后，代码回退就很困难了。
二、使用分支的主线开发
使用分支的主线开发.png
这种分支策略先前有使用过，每个开发者都有自己专属的分支，这样的分支策略很好理解，大家只需要专注自己的工作，各司其职就可以了。但遇到前后端分离或者功能依赖的时候，就要经常同步代码到master，就会退化为上一种分支策略。
三、功能分支部署
功能分支部署.png
在团队更大或前后端分离得情况下，一个需求功能常常需要多个人合作完成，那么分支就应该按功能划分，粒度小到刚好能容纳一个完整的需求功能。功能开发完成后，就合并到集成分支发版，如果验证之后没有问题，再将集成分支的代码合到master。这样虽然分支数量会很多，但可以保证多人协作的畅通，并且由于用集成分支进行部署发版，如果出现问题也可以用master分支恢复版本，可以进行简单的版本管理。
四、状态分支和功能分支的结合
代码在各种环境的流向.png
一个项目的迭代有开发→测试→发布等不同的过程，在这些过程中，代码会迁移到不同的环境，不同环境也应该有自己的分支。
状态和功能分支结合.png
这也是当前使用的分支策略，其实是将集成分支分为了测试、预发分支，方便在不同的环境下出现问题，进行修复或代码回退。举个例子，在一个版本开发中，到了预发阶段发现了问题，随即进行修复再同步到测试分支和master分支。确保经过测试和修复的代码，在测试、预发、生产环境中运作正常。
