作为一个开发者，多人协作，共同开发维护一个项目是很平常的事情。而git作为现下，比较主流的代码管理仓库，想必绝大多数人都应该会使用。
但是在实际应用过程中，会面临很多的，各种各样的麻烦事情。特别是，多人协作，长期性项目。很多人或者很多团队，对项目代码仓库的管理非常的混乱，没有一个固定章法，团队中的成员，各自有各自的玩法。导致了常常出现，代码冲突，代码被覆盖等突发情况。
我所在的项目组，从零到有。从开始的混乱，到慢慢的规范，我完整的经历了整个过程。加上，需求混乱，版本迭代周期短，频率高，对于整个工作流程要求颇高。我也完整的体会了一下，流程混乱的痛苦，和流程规范的重要性。在此大致的做个总结，希望对大家，有所帮助。如果有什么说的不对的地方，也请大家指正，谢谢。
首先，介绍一下我们的工作流程，大致分为以下几个分支：
大致说明一下，各个分支的作用：
- 测试环境分支：对应测试环境，用于开发人员，内部调试，以及测试人员初次测试，更新频繁，代码最新，功能最全，最不稳定。这个分支应该是只接受，从别的分支合并到该分支上，而不应该将这个分支，合并到别的任何分支。它应该是一个黑盒子，只进不出！
- 预发布环境分支：对应预发布环境，测试人员完成初次测试后，将会把即将要上线（发布正式环境），的功能代码推到该分支，产品将会对，需要上线的需求进行验收。该分支，相对稳定，最贴近生产。这个分支应该是只接受，从别的分支合并到该分支上，而不应该将这个分支，合并到别的任何分支。它应该是一个黑盒子，只进不出！
- 生产环境分支：生产的代码（也就是正在线上跑的），分布正式环境时应当使用该分支，当正式代码，运行一段时间后，确定没有问题后，再把这个分支，推倒master。
- master：主分支，基本上和生产环境分支保持一致，该分支不应该做任何认为的操作，只当生产分支，稳定后将其合并过来。
- bug分支：修复bug时，一个bug对应新开的一个分支。这里非常建议这种做法，一个bug一个分支，优点在于，改好一个就可以上线一个，不会影响到别的功能，非常灵活。
- 版本1分支…版本n分支：正在开发的版本，可能是多个版本并行，这是非常常见的事情。个人建议，多人协作时，每个版本，每个人单独一个分支，或者多个分支。把版本细化，一个分支只做一个或者多个相互关联的功能。
- 版本外的单独需求分支：实际开发中，经常会有一些零碎的紧急需求，该分支就是对应这种情况。
上面说了各个分支的作用，接下来，介绍一下工作的流程：
正常的版本开发上线流程，如下图：
如上图，我们应该使用，自己的版本分支（或者bug分支），往对应的环境分支合并。
1.新版本开始时，新建一个对应版本的分支。
2.开发完成后，本地自测没有问题后，把版本分支合并到测试环境分支。
3.测试人员，在测试环境，进行测试，测试通过后，把版本分支合并到预发布分支，注意是版本分支，而不是测试分支直接合并。
4.当产品或者需求方，在预发布环境验收通过后，把版本分支合并到生产环境分支，然后等待发布。
5.当发布生产成功，并运行一定时间，确保没有问题后，再把版本分支合并到master分支上，然后版本分支，就没有什么作用了，此时完全可以删除了。
注意：
每次我们在把版本分支往别的分支合并的时候，尽量都应该先把master合并到版本分支一下，或者定期把master分支合并回版本分支。因为，你的版本周期长的时候，可能会有别的版本或者bug，优先上线了！
比如：
我版本1测试通过了，现在要发布到预发布环境去验收。我应该是使用版本1分支，直接合并到预发布分支，而不应该测试分支合并到预发布分支。
测试环境的分支和预发布环境的分支还有生产环境的分支，作为三个封闭的分支，我们只往里面合并代码，而不将他们合并到其他任何的分支。这样做的好处就是，可以任意的把自己想要的功能发布到对应的环境，而不用担心其他的不应该在这个阶段发布的代码被合并过去。
事实上git本身是有类似的功能的，但是为什么不用，反而采取这样的呢。那是因为，在实际操作中，这种方式虽然笨，但是使用起来，最简单、最直观、最不容易出错。
接下来有几点我自己的建议：
1.不管是新版本，还是bug还是做别的，建议我们通过issues的方式。因为，issues可以让我们保留一些有用的信息，即使分支被删除了，这些信息依然会保留，方便我们以后查找。
2.如果你是使用命令行，那么一定要养成一个良好的习惯，不管是做合并还是推送，请一定要在这之前先pull一下！
3.如果代码又冲突，竟可能的不要使用，工具的一键解决的功能，尽量的对比一下冲突的代码。因为，并不是所有的冲突，都是只保留一方的代码就可以的，有的时候可能两个版本的代码都需要。