分支能够使开发工作更有条理，可以将正在开发的代码跟那些已完成的代码、已测试的代码和稳定下来的代码隔离开。不但使开发协作更加高效，而且也为系统升级和问题修复的部署打下自动化的基础。
在master/trunk分支上编码
即使你不了解分支概念，但只要使用VCS，就已经在使用分支了。VCS系统默认就已经有了一个分支，我们从一开始就在这个分支上提交代码：
- Subversion里的默认分支名为trunk，存在trunk目录里
- Git的默认分支名为master
每个VCS在处理分支的创建、合并和操作行为时，机制不尽相同。
分支的好处
使用分支会有一些成本，但其价值巨大。
适合进行特性开发和Bug修复
任何一个特性开发、负责Bug修复都创建分支，能够避免并行工作是对研发代码的干扰，提高团队协作效率。只有当针对分支的开发工作完成后，才能合并和删除这个分支。
最佳实践：
- 尽量避免将未完成的代码提交到代码库的默认分支上
- 稍微负责一点的工作（特性、修复复杂bug）都应该创建分支
- 开发分支被合并到稳定版的分支后就把它删除，这样代码库会很干净
隔离不同服务器环境的代码
可以使用分支存储不同服务器环境的代码。
代码从开发到上线，一般都会有stage、stable、production等环节,我们可以将这些环境的代码用不同的分支管理起来，就叫stage、stable、production。
每个分支完成当前阶段的工作，符合条件后合并到下一个环节的分支，直至最终部署。各个分支各司其职，互不干扰，降低协同的复杂度。而且可以随时查看不同分支间的差异，快速准确地定位代码的差异，对其进行评审，为寻找劣质代码、不完整的代码、调试代码或其他遗留问题创造了极好的机会。
切记，无部署不合并。服务器分支的代码要保证跟服务器环境上的代码保持同步，如果还没有做好部署的准备，就不要将上一个环节的分支合并到本环境的分支上。否则就会导致本环节的分支代码状态跟服务器代码状态不一致。
使用服务器环节分支，代码变更要严格遵循这样的合并顺序：
- 特性分支或bug分支 => stage，用于测试
- 测试完成后，特性分支或bug分支 => stage，用于构建
- 从stable => production，用于部署
遵循这个顺序，代码的提交历史就很清晰，而且我们也能很确信地知道哪个环境允许的哪些代码。
最佳实践：
- 使用代码库的默认分支作为"stable"分支
- 为每个环境创建一个分支，包括staging和production
- 无部署不合并
- 合并之前查看分支间的代码差异
- 分支合并顺序是单向的
注意：本文归作者所有，未经作者允许，不得转载
