GIT 简单版

Git规范

by 程序亦非猿 2016.4.6
这又是一篇我在公司分享的，想制定一下Git的规范，有兴趣的可以看看~
上一篇在这里

分支模型

每个项目必须要有master、develop分支。
每个开发人员拥有一个自己的分支，如yfy、chz。

master 分支

master 分支只能存在release版本的代码，并需要对每个release打对应的tag。

develop 分支

develop 由master分支检出，它作用主要是日常开发合并代码，并与master分支做交互。
当参与开发的人员较多时，可指定一个人管理develop分支，专门负责合并代码，便于管理，避免多人同时使用develop分支而出现问题。

另外当功能开发完毕后，代码合并入develop分支，测试完成通过后，merge到master分支，并在master上打tag。

开发人员自己的分支

开发人员自己的分支，由develop分支检出，是自己负责的功能分支的上游

工作流程

Feature （新需求开发）

当有新需求需要开发时：

1. 每个开发人员在自己的分支上检出一个新的feature分支，如在czn上检出feature_search分支
2. 在新的feature分支上进行开发
3. 新功能开发完毕后合并到自己的分支
4. 所有人员的分支合并到develop分支，并进行测试
5. 测试通过后合并到master，并打tag

Hotfix （紧急修复bug）

当有紧急bug需要修复时

1. 从master 拉分支hotfix_xxx
2. 修复完毕后合并到develop分支
3. 测试完毕后合并到master分支，并打tag

小结

分支模型已经工作流程大约如图所示：

Git分支使用心得

在去年的大约这个时候，我的领导让我研究一下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分支也一定不会有冲突，否则肯定是你发布分支代码有问题。

发布完成

发布完成之后，master分支的代码就是我们本次迭代发布的代码了，那么需要打出一个tag在服务器上，用项目名称及本次迭代版本号作为tag的名字，本次发布内容作为tag描述，方便下次代码出现问题时可以直接在tag的基础上打出分支进行修改；本次迭代的发布分支及个人的开发分支都可以删除掉，主开发分支需要保留，方便以后查询及找回代码使用，设置主开发分支的开发权限为只读权限，这样谁都无法删除和推送代码。

发布之后出现bug

如果在开发中或者发布之后线上的程序出现bug怎么处理？按照我的经验来说的话，先保存自己的开发代码，然后从master分支打出一个临时修改bug分支：

studentsystem_v1.1_emegencydebug_from_master(0814build)【紧急bug修复分支】

如果不是很紧急，可以跟本次迭代发版，那么也可以从正在开发的分支上直接修改。

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