分支管理模式
15.1、开发阶段
1)
除了master
分支创建一个供所有开发人员开发的dev
分支;
2)
开发人员在dev
分支上进行工作,随时随地commit
,每天push
一次到服务器;
3) push
代码前需要进行pull
操作,因为有可能在之前有别的成员先进行了push
操作,如果有冲突还需要进行冲突解决;
4)
每天上班后所有成员对dev
进行pull
操作,获取所有成员push
的代码,有冲突需要解决;
5)
团队Leader每天将dev
合并一次到master
。
15.2、测试阶段
1)
测试进入后就需要添加test
分支;
2)
在开发人员将代码push
到dev
分支后,可以在dev
基础上创建test
分支,测试人员以test
分支搭建测试环境,开始测试;
3)
开发人员在接收到bug
后,直接在测试分支上修改,然后让测试人员进行验证;
4)
每天团队Leader将测试分支上修改的bug
合并到dev
分支上,这样所有团队成员当天修复的bug
都会在第二天被团队其他人pull
下来;
5)
团队Leader每天将dev
合并一次到master
。
15.3、上线阶段
1)
系统上线后试运行阶段会存在两种改动:bug
和优化需求,bug
通常当天解决晚上部署,优化需求通常周末部署;
2) bug
当天能修复的就直接在test
分支上修复,然后进行测试,验证通过后合并到master
;
3) bug
当天不能修复的就针对该bug
创建一个分支,修复完后合并到test
分支进行测试,验证通过后合并到master
;
4)
每个优化需求都以master
分支为基础创建一个feature
分支,完成后合并到dev
分支,开发人员可以先交叉测试,然后将dev
合并到test
进行测试,验证通过后合并到master
;
5) master
始终是一个干净的,可发布的分支。
15.4、merge request模式
1)
需求或是Bug
都是用Issue
来表示;
2)
虽然Issue
不支持多层级,但结合里程碑、标签等还是可以很好的对任务和Bug
进行管理;
3)
管理员和团队成员都可以进行Issue
的创建;
4)
任务的接收者对Issue
创建Merge Request
;
5)
完成任务后推送代码到Merge Request
对应的分支;
6)
管理员对代码进行Merge
。
15.5、merge request工作流程
1)设置重要分支受保护
2)创建issue
3)任务创建后,开发人员就可以根据该任务创建Merge Request
了
------------------------------
初始化版本库,并提交到远程服务器端
mkdir WebApp
cd WebApp
git init本地初始化
touch README
git add README添加文件
git commit -m 'first commit'
git remote add origin git@github.com :daixu/WebApp.git增加一个远程服务器端
上面的命令会增加URL地址为' git@github.com :daixu/WebApp.git',名称为origin的远程服务器库,以后提交代码的时候只需要使用origin别名即可。