在去年的大约这个时候，我的领导让我研究一下git的使用方法，方便我们自己的代码管理，因为我们原先使用的是SVN，使用起来没那么方便，所以让我研究研究git的使用。我就简单的研究了两天，用我的IDE(vs2015)试了下，还不错，然后开发了一个月之后，整个部门都换成了git进行项目代码的版本控制。到现在为止已经使用了git接近一年了。

       就是因为当初简单的研究了两天，这接近一年的时间里只是使用的git的基本功能，没有把git分支的强大使用起来，在两个月前发现了我们使用的git分支的问题，所以在分支使用方面进行了改进，把我的心得也给大家分享一下。

       关于分支的使用，我从网上找到了一些相关的资料，网上常见的分支使用是分三种：master(主干)、develop（开发）、publish(发布)三种常规分支。而我们根据网上的先进行了一个迭代，而后觉得有点不符合我们的使用场景，所以我们自己又有了其他的使用方式，下面我给大家分享一下。

       项目的初始时会默认有一个master分支，也就是我们常说的主干分支，主干分支的代码与线上运行的代码是一致的，而且平时开发的代码不能推送到master分支上去，所以master分支平时是锁死的，也就是设置成只读的，任何人都不能推送代码到master分支上去。

       假如我们现在有个学生管理系统的项目【StudentSystem】,我们要开发一个新功能—考试功能。那么我们需要建两种分支，一个是发布分支，一个是开发分支。

关于开发

         发布分支的创建时间也分两种，一种是开发之前就建好，另外一种是开发完成之后创建开发分支，不管是哪种，发布分支的代码始终是与master分支的代码是一致的。

       咱们采取第一种，开发之前就开始创建发布分支。

发布分支名为：

         studentsystem_v1.0_exam_publish_from_master(0812build) 或者 studentsystem_v1.0_考试功能_发布分支_from_主干(0812创建)

       项目名字_版本号_分支状态_from_从哪个分支创建(何时创建)

       总之分支的名字让人看到后能明白这个分支是做什么的即可。

开发分支：

       studentsystem_v1.0_exam_develop_from_publish1.0(0812build)  或者  studentsystem_v1.0_考试功能_开发分支_from_发布分支1.0(0812创建)

       网上查到的资料是到这里就完事了，但是我们开发项目，开发这一个功能是需要2个或者大于2个人的，多人在同一个分支下开发的话，肯定会有冲突，而且不好进行代码审核，所以我们使用了git的pull request,所以就有下面的，

再创建个人的开发分支

       从主开发分支创建个人开发分支，命名如下：

       studentsystem_v1.0_ls_exam_develop_from_develop1.0(0812build)  或者  studentsystem_v1.0_李四_考试功能_开发分支_from_开发分支1.0(0812创建)

       这样就可以每个人有一个自己的开发分支，每天下班之前提交当天的代码到服务器上，然后提交pull request使代码合并到主开发分支上去，就可以方便大家进行代码审核。

       然后第二天早上上班之后首先修改昨天提交的pull request中被别人发现的问题，再提交代码到服务器上，等待所有的pull request被审核通过后，大家要从主开发分支上拉取代码合并到各自的开发分支上去。

最后再进行自己今天的开发任务即可。 

关于测试

提交测试之前

       保证所有的开发人员的代码已经全部提交到服务器上并全部通过了pull request。然后把主开发分支(studentsystem_v1.0_exam_develop_from_publish1.0(0812build))的代码拉取到本地合并到最新的发布分支(studentsystem_v1.0_exam_publish_from_master(0812build))【这就是我说开发之前创建可以，开发完成后创建也可以的原因】上去，但是，合并之前一定要保证发布分支上的代码是与master分支的代码是一致的，否则测试等于白测。记住：向发布分支上合并代码是不会有冲突的，如果有冲突说明你发布分支的代码不与master分支的代码一致或者你的开发分支代码有问题。

提交测试后

        我们项目的测试是分两轮：第一次测试和回归测试。在测试期间不能往测试环境中发布新的代码（就是说在进行第一轮测试的时候，出现了20多个bug，开发人员修改的比较快，在测试人员还未完全测试一轮的情况下，已经修改了大半，这种情况也不要发布新的测试版本，否则测试人员的第一轮相当于白测，覆盖了测试人员原先的测试成果。一定要等测试人员完全测试一遍才可以发布新的测试版本。），

如果遇到了阻塞的bug怎么办？

          这样也不能发布新的测试版本吗？这样肯定是可以发布新的测试版本的，但是新的测试版本不是从开发人员正在开发的分支合并到发布分支上去，然后发布到测试环境中，而是从发布分支上打一个修改阻塞bug的分支出来：

      studentsystem_v1.0_exam_[block_bug_name(bug的名字) or block_bug_code(bug的编号)] _from_develop1.0(0827build)

修改完成后合并到发布分支上去，然后发布到测试环境中，这样就不用打断或者影响测试正在进行的测试了。也就是说发布分支的代码与测试环境的一致。

重要的：

      发布分支权限设置为保护分支【只有管理员才可以推送代码到服务器上】，这样保证入口的唯一性，只有本次迭代负责人才可以合并代码到发布分支上去。

关于发布

发布我们分为预发布和正式发布。

       预发布就是模拟真实发布环境进行发布，执行sql脚本，修改相关的配置，把发布分支的代码发布到预发布环境中。

       说到这想起来一件事：我们每次进行项目的预发布时，总是很顺利，速度也很快，也没有遇到问题，然后在正式发布的时候，总是遇到各种问题，各种不顺利，所以这就导致预发布是没有意义的，正式发布后与测试环境下的功能也不一致，就是测试环境和预发布环境下功能么有问题，正式发布时也有问题。本次迭代结束后，我们经过讨论后想到了一个解决方案：就是发布测试环境也需要服务器管理人员（也就是测试人员）输入服务器密码，就是说测试服务器、发布服务器、正式服务器的密码只有测试人员知道，只有在发布测试版本的时候，只有测试人员输入密码后才可以发布新的测试版本到服务器上。开发人员使用开发服务器即可，只需要保证开发服务器上的数据库数据和数据库结构与正式的一致即可。

        正式发布的时候可以是发布分支代码，也可以把发布分支的代码合并到master分支上，然后进行发布，注意：从发布分支合并到master分支也一定不会有冲突，否则肯定是你发布分支代码有问题。

        以上就是我遇到的问题和解决方案以及git分支的使用心得。

Git分支使用心得