举一个产品开发的栗子
1、一个boss管理5个产品经理
2、5个产品经理分头给baidu设计产品需求，需求之间没有交集，各人写各人的文档，设计各人的原型，谁的需求合理，有创新，有价值，谁的需求优先级就高，这个boss谁说的算。文档不全、不合理的需求自然就没法开始做，这个产品经理的绩效自然也比较低，互相之间有很强的竞争意识
3、到这个阶段有可能已经有3个需求通过了boss的审核，进入UI设计阶段
4、到这个阶段，UI已经设计完成，开3个产品评审小会，把任务分配给相关的三组人员（一个人可以同时在多个组里）
5、3小组建立3个分支（前后端同一个需求建的分支名称要完全一样），分头开发，产品经理实时跟进，测试人员实时沟通，边开发，边变更需求、边测试（测试在不同的分支上测）
6、如果有需求开发测试都完成了，这个分支就合并到develop分支上，测试在develop分支上再测试一遍，确保没有bug，如果有bug，重新建立分支，改完后，在新分支上测试，测试完再合并到develop分支上。所有人不得在develop上写任何代码，只能建立新的分支写代码，而且分支如果想要合并到develop上，必须经过严格的测试后才可以合，程序员没有合并分支的权利，测试和运维有
7、这时候或许又有2个新需求通过了boss的审核，而且UI也已经设计好，刚好这个时候有一组程序员做的需求已经通过测试，可以直接应对新需求了
8、develop本身就是一个很稳定的版本，可以随时从develop分支合并到master分支，销售周一要产品，就周一给，周五要产品就周五给。无论是周一的产品还是周五的产品，都是稳定的产品，只是或许周一到周五这段时间里修复了几个以前没有发现的比较隐藏的bug或许增加了一些新功能而已。市面上的所有app也都是如此，每次提醒用户安装新版本都会告诉你，他们修复了一些bug，增加了一些新功能
9、产品经理才是一个公司的灵魂，程序员不是
其他：
1、feature分支和develop分支的运行环境是完全一样的，其实在git软件看来，feature和develop是平级的，只是人为的认为develop更高级些而已。为保证feature向develop合并代码的时候出现冲突和覆盖，可以在合并前先将最新的develop（有可能别的分支已经向develop合并过代码）合并到自己的feature分支上，如果有冲突，就解决冲突后再提交到自己分支上，然后进行测试，这时候自己的feature分支就完全和最新develop分支代码一样了，只是多了自己新增加的功能，而这些功能要经过充分的测试才能合并到develop分支上。
2、如果有个功能做了一半，产品经理感觉这个功能不合理，可以直接把这个feature分支废弃掉，完全不影响develop分支和产品稳定性
3、feature分支和develop分支的运行环境是完全一样的，如果有个bug在develop可以复现，在feature上不能复现，就要质疑运维的环境问题。如果有个bug在develop可以复现，在feature上也能复现，但是之前测试在feature上测试时没有发现，到develop上才发现，就要质疑测试是否用心测了（建议直接罚款）
4、develop分支和master分支上的bug是测试和运维的锅（建议直接罚款），如果不是bug是产品本身有缺陷，那就是产品经理的锅（建议直接罚款）。出现这类问题时相关人员需要和程序员好好说话，态度要好，认错要诚恳，然后程序员再修复这类问题，不然他们会总是犯这类错误！
5、程序员总是会经常出错的，但是我们的错误应该在feature分支被发现
6、这个例子说的场景是只有一款产品，多个产品经理为这个一款产品设计不同的需求
7、我推荐的这套方案可以解决新需求及时上线，实时都有稳定版本，产品经理比较多，开发人员也比较多时，每个需求优先级不同，进度不同，上线顺序也是随机的
参考链接：http://blog.jobbole.com/109466/
参考链接：
分支管理和自动化部署的 原型图