Git版本管理工具操作规范 V11.docx
《Git版本管理工具操作规范 V11.docx》由会员分享，可在线阅读，更多相关《Git版本管理工具操作规范 V11.docx（8页珍藏版）》请在冰豆网上搜索。
Git版本管理工具操作规范V11
Git版本管理工具
操作规范
2017年5月
修改记录
编号
日期
描述
版本
作者
审核
发布日期
1
新建文档
刘田
李凯靖
/
/
2
调整文档结构，增加站点容器系统的git操作规范相关内容，增加各系统工作流说明
李凯靖
李铁山
3
4
1引言
1.1文档目的
本文档旨在制定统一的Git版本管理工具的日常操作规范，解决因不规范操作而引起的系统异常问题，提高开发人员、测试人员、运维人员的工作效率与质量，提升系统运行的稳定性。
1.2适用对象
本文档适用于所有开发人员、测试人员、运维人员等相关技术人员使用。
1.3适用范围
本文档适用于Git版本管理工具（OA系统与站点容器系统）。
2分支命名规范
分支
命名规范
开发分支
Dev
测试分支
Test
Beta分支
Beta
生产环境分支
Master
新开发分支
姓名拼音_[bug|task]_编号_简要描述
新测试分支
姓名拼音_[bug|task]_编号_简要描述
3操作规范
3.1OA系统
3.1.1工作流
OA系统采用四条主分支的管理方式，分别为开发分支Dev、测试分支Test、Beta分支以及生产环境分支Master，其工作流如下图所示：
OA系统工作流示意图
3.1.2开发人员日常操作规范
3.1.2.1克隆分支
适用场景：
开发人员第一次操作或后期特殊情况需要重新克隆分支时执行此操作。
操作步骤：
右键Git克隆-》输入源码地址，设置分支名称（开发人员固定为Dev）-》确定完成。
3.1.2.2创建新分支
适用场景：
开发人员有新的任务或BUG时需要创建新分支处理时执行此操作
操作步骤：
在主开发分支下右键拉取-》右键创建分支（分支命名规范：
姓名拼音_[bug|task]_编号_简要描述），填写相应描述-》右键“切换/检出”切换到新添加的分支。
3.1.2.3提交修改内容
适用场景：
开发人员创建的开发分支完成或暂停任务时执行此操作
操作要求：
不要求每做一次操作都进行一次提交，但是当需要切换分支或是进行推送、拉取分支时，要求必须提交当前的操作（新增文件一定要记录加入到Git上）。
提示：
提交只会提交到本地不会影响别人的代码或是主开发分支。
3.1.2.4推送自己的开发分支到远端
适用场景：
开发人员将一个任务或BUG处理完，需要将分支推送到远端时执行此操作。
操作步骤：
在当前自己的开发分支下右键推送（先提交后推送）-》输入远端分支名称（与当前本地分支名保持一致）-》确定完成。
3.1.2.5合并自己的开发分支到主开发分支
适用场景：
当测试人员反馈安装包己经测试通过，此时开发人员需第一时间将已通过测试的开发分支合并到主开发分支。
操作步骤：
提交自己手上正在处理的分支-》切换到主开发分支上-》右键拉取主开发分支-》右键合并（找到对应的开发分支）-》确定完成（如发生冲突则先解决冲突）-》右键推送（合并后的代码必须要推送到远端主开发分支上）。
3.1.3测试人员日常操作
3.1.3.1克隆分支
适用场景：
测试人员第一次操作或后期特殊情况需要重新克隆分支时执行此操作。
操作步骤：
右键Git克隆-》输入源码地址，设置分支名称（测试人员固定为Test）-》确定完成。
3.1.3.2创建新分支操作
适用场景：
测试人员需要对开发人员的代码进行测试时必须创建新分支来处理。
操作步骤：
在主测试分支下右键拉取-》右键创建分支（分支命名建议：
姓名拼音_[bug|task]_编号_简要描述）,填写相应描述-》右键“切换/检出”切换到新添加的分支。
3.1.3.3合并开发人员的代码
适用场景：
测试人员需要先合并开发人员的代码，再开展测试工作。
操作步骤：
在当前自己的测试分支下右键合并-》搜索并选择相应开发人员的分支-》确定合并（如果出现冲突，请告知开发人员自行解决冲突后，再重新提交）。
3.1.3.4合并自己的测试分支到主测试分支
适用场景：
测试通过后测试人员需要将代码合并到主测试分支上。
操作步骤：
右键切换到主测试分支-》右键拉取最新的主测试分支-》右键合并（找到对应的测试分支）-》确定完成-》将程序发布到IIS上再进行一次测试-》测试完成后右键推送（合并上来的代码必须要推送到远端主测试分支上）。
3.1.4运维人员日常操作
3.1.4.1克隆分支
适用场景：
运维人员第一次操作或后期特殊情况需要重新克隆分支时执行此操作。
操作步骤：
右键Git克隆-》输入源码地址（Beta环境需要设置分支名称为Beta，Master环境无需设置分支名称）-》确定完成。
3.1.4.2beta环境发布
适用场景：
运维人员需要进行beta环境版本发布时。
操作步骤：
右键拉取最新的Beta分支-》右键合并（找到主测试分支）-》确定完成-》提交到Beta本地仓库-》推送到远端Beta仓库
3.1.4.3正式环境发布
适用场景：
运维人员需要进行正式生产环境版本发布时。
操作步骤：
右键拉取最新的Master分支-》右键合并（找到主Beta分支）-》确定完成-》提交到Master本地仓库-》推送到远端Master仓库
3.2站点容器系统
3.2.1工作流
站点容器系统采用两条主分支的管理方式，分别为开发分支Dev与生产环境分支Master，其工作流如下图所示：
站点容器工作流示意图
3.2.2开发人员操作规范
操作项目
详情
克隆新分支
参考
创建新分支
参考
提交修改内容
参考
推送自己的开发分支到远端
参考
打包安装包
开发人员需在模块根目录创建文件，并将相关信息打包为安装包提交测试人员测试
合并自己的开发分支到主开发分支
参考，但如果修改的代码涉及多个模块，需相关模块都测试通过，才能进行开发分支的合并操作
3.2.3测试人员操作规范
3.2.3.1发送安装包给运维
适用场景：
开发分支打包为安装包，对涉及模块进行测试并测试通过后执行该操作。
操作步骤：
按照发布计划将安装包提交给运维人员，进行发布。
3.2.3.2合并开发分支到生产环境主分支
适用场景：
运维将安装包发布到线上后，对应的开发分支需合并到生产环境主分支。
操作步骤：
右键切换到Master主分支-》右键拉取最新的Master主分支-》右键合并（找到对应的开发分支）-》确定完成-》推送到远端（合并上来的代码必须要推送到远端Master分支上）。
4操作重点注意事项
4.1开发人员注意事项
4.1.1合并代码操作注意事项
合并代码前，必须从主分支上拉取最新的代码，再进行合并。
进行代码合并时，要求开发人员不能覆盖他人代码，如出现代码覆盖导致系统异常的问题，发现人需自行确认责任人，未及时查找责任人，则由发现人承担责任。
责任人需协助问题发现人进行问题修复，不允许出现不理睬不处理。
提示：
出现代码覆盖问题，目前推荐的解决方案由被覆盖了代码的责任人重新提交本地代码。
如果修改的代码涉及多个模块，需相关模块都测试通过，才能进行开发分支的合并操作。
当测试人员告知开发人员已经测试通过时，开发人员要第一时间将分支合并到主开发上，以免出现其他人拉不到最新的代码造成后期代码合并测试时产生冲突。
4.1.2解决代码合并冲突注意事项
当出现冲突时，由当前开发人员负责解决冲突，如需要其他人协助解决冲突，请积极与相关人员进行沟通。
如果开发人员在解决冲突时需要另一个开发人员协助，另一个开发人员需全力协助，不允许出现不理睬不处理。
当测试人员合并代码时出现冲突，开发人员需积极解决冲突，但不能影响测试人员的正常工作（如使用测试人员的电脑解决冲突）。
4.1.3配置文件操作注意事项
开发人员不允许添加配置文件，包括但不仅限于以下配置文件：
App_Data
bgservice的
4.2测试人员注意事项
4.2.1解决冲突注意事项
如果程序出现冲突必须由开发人员进行解决，测试人员不能擅自修改程序代码，不能私自解决，更不能为了解决冲突而还原开发人员的代码。
4.2.2配置文件操作注意事项
测试人员不允许删除配置文件，如出现跟配置文件相关的报错，请进行还原配置文件操作。
提示：
如果合并时配置文件被删除，测试人员可以在操作日志中将配制文件还原。
4.2.3分支合并注意事项
合并分支前，必须拉取最新的分支，再进行合并。
测试通过后测试分支，成功合并到主测试分支上后，测试人员需第一时间通知开发人员，当前分支已测试通过，便于开发人员进行开发分支合并到主开发分支操作。
测试通过后的开发分支，需按照发布计划，将安装包发给运维人员进行发布，同时应及时将相应的开发分支，合并到Master主分支上。
4.3运维人员注意事项
4.3.1分支合并注意事项
OA系统进行分支合并前，必须从（Beta/Master）环境拉取最新的分支，再进行合并。
4.4个人账号管理
各系统对角色、个人的账号都有相应的权限管理机制，请妥善管理个人账号，不得转借他人使用。
5定责标准
5.1对日常工作造成影响
对于违反Git操作规范者，将综合实际情况，参考以下标准进行处罚：
影响范围
分值
1分
2分
3分
4分
修复时间
0-1H
1-2H
2-4H
4H以上
直接影响人（其他开发团队）
0-3人
4-6人
7-9人
10人或以上
投诉量（用户）
0-3人
4-6人
7-9人
10人或以上
严重程度
分值
处罚标准
严重
11-12
100
中等
9-10
50
一般
6-8
30
轻微
3-5
10
若出现问题不在本规范定义内，将以公告形式进行警告，后续增加对应的规范。
系统因git操作不规范引起异常时，相关人员如不配合修复问题，或故意延长修复时间，则以当前严重程度为标准再进行定责（如由于A人员合并代码时，覆盖他人代码造成异常，严重程度为轻微，但其不配合做修复，或故意延长修复时间，则以双倍进行处罚）。
5.2造成公司经济损失
对于违反Git操作规范，或因非正常操作对Git内项目造成损坏，直接造成公司经济损失的，将按照实际情况评定处罚结果。
升级会员 