gitlab使用（第二弹）

@(gitlab)[版本创建|回滚]

gitlab 项目创建

详见文档如何使用gitlab管理项目

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中，避免下一个版本遗漏

说明：文章为自己的个人经验只谈，个人操作习惯或有不同，代码管理方式也可能存在差异，只要抓住核心，代码不混乱，可追溯即可，欢迎讨论辩证，不喜勿喷！