大项目的代码管理机制

我们之前已经熟悉了git工具（详情请查看：5分钟熟悉git工具）
如果是项目是初创期，研发团队成员只有几个人，那么git用不好，对项目影响也不会太大。
如果项目已经初具规模，研发团队在数十人以上，那么项目代码管理，就是一门非常具有艺术性的工作，处理不好将会带来灾难性的后果。
今天我们通过一些工作需求场景及其对应的解决方案，来快速熟悉掌握在大项目大团队中如何通过git进行有效的代码管理。相信聪明的你，看完一定会有收获！

【正文开始】

初创团队的工作流程，一般是：
1）业务功能A开发完了，提交测试部门进行测试
2）测试部门测试完了，提交到运维部门进行生产环境部署

看上去工作非常顺利，但项目初具规模后，以下新问题会陆续产生：
1）测试部门尚未完成功能A测试，产品就下发了功能B的研发任务；
2）研发人员继续在master分支上研发功能B，测试部突然告知功能A有缺陷需要整改；
3）有些时候，测试部工作出现问题，导致错误没有被发现，而被提交到了生产环境
.....

可能已经有小伙伴感觉需要开分支进行管理了，但开第2个分支就能解决上面的新问题吗？答案显然是否定的。

作者借助自己多年的项目管理经验，在这里介绍一下分支的设计艺术，有问题或建议的小伙伴，可以在评论区留言互动。

对于一个足够复杂的项目，我们最少需要 5个分支进行管理，各分支名称及其适用场景（要解决的问题）说明如下：

1）master 分支
这是主分支，新功能需求的开发工作都需要在此分支上进行；

2）test 分支
这是测试部门使用的分支，当master分支上某个阶段性的开发工作结束，合并到test分支进行提测。

3）release分支
这是生产环境使用的分支，当测试部门测试通过后，需要将test合并到release。

4）master_bug 分支
当release 发布以后，需要立即检出 master_bug 分支
如果生产环境需要紧急消缺，则直接让研发人员从 master_bug上进行修改

5）test_bug 分支
当release 发布以后，需要立即检出 test_bug 分支
master_bug修改完毕后合并到 test_bug，最终由test_bug合并到release完成生产环境的缺陷修复

两个问题答疑：

1、问: 为什么不从master_bug 合并到 test呢？
答：因为当项目足够复杂时，test_bug（release） 跟 test 功能代码已经差的很多了，强行合并对relase会影响较大，风险较高。

2、问：为什么用这么多分支管理？用tag标签管理不行么？

答：真实的项目生产环境部署流程，一般都要经历研发部，测试部，运维部等多人协作，跨部门协作的效率过来人都懂，经历一番寒彻骨之后，得出的结论就是要想效率高，人参与的越少越好。现在业界基本都是在使用自动化运维工具（比如jenkins）进行相关工作，而对于这些工具，严格的branch分支名称，相对于随意性较强的tag标签，更容易配置。