gitlab使用（第二弹）

meimei10251314

　　# gitlab使用（第二弹）
　　@(gitlab)[版本创建|回滚]
　　## gitlab 项目创建
　　> 详见文档[如何使用gitlab管理项目](http://files.cnblogs.com/files/shunzizhan/%E5%A6%82%E4%BD%95%E4%BD%BF%E7%94%A8gitlab%E7%AE%A1%E7%90%86%E9%A1%B9%E7%9B%AE.pdf)
　　## gitlab 版本创建
　　### 版本创建的意义
　　- 记录了你每一个版本新增了那些需求，修复了那些bug，能够完整的体现你项目的整个研发轨迹
　　- 对于临时性质的bug修复，能够保证继续向后开发，又能紧急修复，不影响研发进度
　　###  如何创建版本
　　#### 故事背景
　　- **项目名称：**test
　　- **团队人员：**A（PM）、B、C
　　- **项目分支：**master、dev、fdc_a、fdc_b、fdc_c
　　- **第一天：**test项目为一个新项目，涉及用户登录、用户头像上传、用户密码修改（`需求1.0`）个功能模块，分别分配给A、B、C完成，A、B、C分别在自己的分支`fdc_a`、`fdc_b`、`fdc_c`着手研发，并`提交到自己的远程分支`，并`创建合并请求到dev`，A、C一个工作日完成，B还没有完成所有功能研发
　　- **第二天：**早上上班，他们都从`dev`拉取到自己的本地分支，三人均可以正常进行用户登录以及用户密码修改，B抓紧时间完成头像上传并`提交到自己的远程分支`，并`创建合并请求到dev`
　　- **第三天：**早上上班，他们都从`dev`拉取到自己的本地分支，A创建版本`dev->dev_1.0`,并发布到测试环境，经过一天的测试及bug修复，功能都没有什么问题，test项目上线，PM在gielab上面创建合并请求`dev_1.0->master`
　　- **第四天：**产品告诉研发需要对`test`进行`迭代`，增加用户注册功能、密码修改需要增加短信校验（`需求1.1`），Ａ、C从`dev`拉取代码到自己的本地分支，开始着手新的研发，两个新的需求完成80%，并`提交到自己的远程分支`，并`创建合并请求到dev`
　　- **第五天：**产品告知，用户反馈头像上传存在问题，需要对`1.0版本`紧急修复，A在gitlab上创建一个标签`dev_1.0->tag_dev_1.0`,然后创建分支`dev_1.0->fdc_b_1.0`,B切换自己的本地分支从`fdc_b`到`fdc_b_1.0`，并紧急修复头像问题，提交测试，测试通过，B `提交到自己的远程分支fdc_b_1.0`，并`创建合并请求到fdc_b_1.0->dev_1.0`,A C完成剩余的`需求1.1`的研发，`提交到自己的远程分支`，并`创建合并请求到dev`
　　- **第六天：**A创建一个合并请求`dev_1.0->dev`,并创建版本`dev->dev_1.1`，打包提测，包含`需求1.1以及回归测试头像bug`,测试通过，没有问题，上线，PM在gielab上面创建合并请求`dev_1.1->master`，`需求1.1`已完成上线
　　- **第N天：**……
　　### 分析
　　项目test完了了2次开发，一次紧急修复，最后出现的分支有
　　- **master **永远记录的是最后一次的上线版本
　　- **dev** 永远记录的是开发版本
　　- ~~*tag_dev_1.0*~~ 版本1.0，一旦dev_1.0修复完毕后，可丢弃，主要作用是放置修复bug的同时，引发其他bug，作为`dev_1.0的线上版本备份`
　　- *dev_1.0* 版本1.0以及紧急修复的一次
　　- *dev_1.1*版本1.1
　　- *fdc_a*开发者分支
　　- *fdc_b* 开发者分支
　　- ~~*fdc_b_1.0*~~ 开发者分支，继承自1.0版本，一旦dev_1.0修复完毕后，可丢弃
　　- *fdc_c*开发者分支
　　### 总结
　　- `master`永远都是目前线上的稳定版本
　　- `dev`只注重项目需求的研发
　　- 那个版本出现问题，就在那个版本上进行bug紧急修复，研发继续朝后进行，一旦bug修复完毕，需要合并到dev中，避免下一个版本遗漏
　　**说明：**文章为自己的个人经验只谈，个人操作习惯或有不同，代码管理方式也可能存在差异，只要抓住核心，代码不混乱，可追溯即可，欢迎讨论辩证，不喜勿喷！