Feature Branch指的是每开发一个新功能、每修一个bug，都打出一个新的分支，等测试通过后才合并到主干。它的反面是"对所有新功能，大家直接在主干上修改代码“
个人对Feature Branch的优缺点有一些体会：
优点：
1.
不同feature之间的开发可以彼此隔离，避免了“一损俱损”的风险。比如，如果大家都在主干上开发，一个人不小心提交了错误的代码变更导致了编译错误，会搞得所有人的code base都无法编译。亲身经验表明，这种事情非常浪费时间、损耗士气
2.
隔离了的分支可以独立进行QA测试，时间上不会互相担误。如果大家都在主干上开发，那主干就用于QA测试，也就是说，张三和李四的改动会集成在一起测试，
a. 如果张三的改动在测试时发现问题，修改后要重build、重启应用，则李四的改动也意味着要被重启，这会浪费测跟李四有关的测试人员的时间。为了避免这种影响，大家只好约定在每天一两个固定的时间点重build、重启。亲身经验表明，这种做法的效率比较低。
b. 如果张三的改动没测通，李四的改动可能也不准发布，因为测试人员不敢确定张三的错误是否与李四的改动有关
3.
确保未测通的改动不会跟别的改动混在一起或进入主干，避免发布时的“选择性代码合并”问题。如果大家都在主干上开发，在发布时只能选择已测通的改动发出去；由于测通了的改动和未测通的改动混杂在主干分支上，所以合并代码到发布分支时，你要小心翼翼，以保证只合并该合并的代码。虽然现在的版本控制工具很强大，但在处理这类事情时如果遇到复杂的情形，往往还是力不从心，仍须人力来辅助。亲身经验表明，用人力做这种事情比较无聊、费时，而且错误率很高。
（待续）
缺点：
1.每次开发都要新建分支、重建开发环境，比较浪费时间
2.如果每个分支独立测试，则意味着每个分支要占一台测试机器，这要求公司的硬件比较充裕。
3.持续集成的利用率不高。对Feature Branch一般不会持续监控，所以持续集成只能作用在主干上。既然健康的改动才会集成到主干上，所以主干基本上也是健康的，这时持续集成基本上是个摆设。
4.一个分支的大改动要很晚才能集成到另一个分支，导致Big Scary Merge问题(Martine Fowler语)。假如张三的Feature改了很长时间，终于在今天归并到了主干; 而李四已有一个分支在改动，当他第二天把主干集成到自己的分支时（日常集成），由于主干的变动很大，他会发现自己可能会遇到非常多的代码冲突，即Big Scary Merge
（待续）