Git代码管理规范
来自ling
目录
常用链接
git config --system http.sslverify false
本次迁移范围
只包含源代码,不包括文档
GitLib有五种身份权限 (项目创建,用户注册,权限开通请联系Eric)
- Owner 项目所有者，拥有所有的操作权限
- Master 项目的管理者，除更改、删除项目元信息外其它操作均可
- Developer 项目的开发人员，做一些开发工作，对受保护内容无权限
- Reporter 项目的报告者，只有项目的读权限，可以创建代码片断
- Guest 项目的游客，只能提交问题和评论内容
分支使用的规则
本规范用于描述日常研发流程中关于GitLab上代码分支使用的规则，大家共同严格遵守规范，避免出现分支管理混乱现象，保证日常的发版上线工作顺利进行。
- Workspace：工作区，平时我们写代码的地方。
- Index：暂存区，写完代码后让它变成的待提交的状态。
- Repository：本地仓库，提交暂存区的代码到这里，记录进入代码本地管理。
- Remote：远程仓库，将本地仓库的修改的代码提交到远程，可以供远程协作的人下载。
分支管理规范主要遵循gitflow的分支管理流程，见下图：
分支定义
常规代码管理流程如下
主要分支（保护分支）
master分支
- 只存线上的代码，只有确定可以上线时的才合并到master上，并且在master的基础上打Tag。
- master 主分支，稳定代码，为生产环境做准备的
develop分支
- develop 开发分支，为开发服务
- 初次创建develop时，需要从master分支拉取，保持开发时代码和线上最新的代码相同。develop分支是在开发时的最终分支，具有所有当前版本需要上线的所有功能。
辅助分支
feature分支
特性分支 从develop分支创建，用于特性开发，完成后要合并回develop分支。
- 用于开发功能的分支，必须从最新的develop分支代码拉取。分支命名基本上是feature/xxxxx（和功能相关的名字）。
- 不强制提交到远程仓库，可以本地创建。
- 比如，我要开发登录功能，我从develop分支的最新代码创建新分支命名为feature/login，然后切换到这个新分支开始开发。开发完成后，测试差不多完成，合并到develop分支。
操作过程：
- git checkout -b newfeature develop，从develop分支创建newfeature特性分支
- git checkout develop，开发完成后，需要合并回develop分支，先切换到develop分支
- git merge --no-ff newfeature，合并回develop分支，必须加--no-ff参数
- git branch -d newfeature，删除特性分支
- git pull origin develop,拉取远程develop分支代码，进行合并
- git push origin develop，把合并后的develop分支推送到远程仓库
release分支
- 当develop分支已经有了本次上线的所有代码的时候，并且以通过全部测试的时候，可以从develop分支创建release分支了，release分支是为发布新的产品版本而设计的。
- 通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。
- 在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。
- 比如，此次1.0版本所有的功能版本都已经合并到了develop上，并且所有测试都已经通过了测试，那我就创建新的release分支release/v1.0。切换到新分支，修改最新的版本号等，不允许大的更改。
从develop分支创建，用于预发布版本，允许小bug修复，完成后要合并回develop和master。 操作过程：
- git checkout -b release-1.2 develop，创建一个发布分支
- git checkout master，切换到master分支，准备合并
- git merge --no-ff release-1.2，把release-1.2分支合并到master分支
- git tag 1.2，从master分支打一个标签
- git checkout develop，切换到develop分支，准备合并
- git merge --no-ff release-1.2，把release-1.2分支合并到develop分支
- git branch -d release-1.2，删除这个发布分支
hotfix分支
- 当线上出现bug需要紧急修复时，从当前master分支派生hotfix分支。
- 修改线上bug，修改完成后合并回develop和master分钟。
- 比如，在线上v1.0登录功能出现问题，我从master拉取代码创建新的分支hotfix/v1.0_login，修改完成后合并到master和develop上。
修复分支
从master分支创建，用于生产环境上的Bug修复，完成后要合并回develop和master。 操作过程：
- git checkout -b hotfix-1.2.1 master，从master分支创建一个Bug修复分支
- git checkout master，切换到master分支，准备合并
- git merge --no-ff hotfix-1.2.1，合并到master分支
- git tag 1.2.1，为master分支创建一个标签
- git checkout develop，切换到develop分支，准备合并
- git merge --no-ff hotfix-1.2.1，合并到develop分支
- git branch -d hotfix-1.2.1，删除hotfix-1.2.1分支
Git协同模型
SVN式集中协同模型
适用于小型项目，参与人员较少的项目，每个开发者均可向仓库推送代码
金字塔模型
适用于大型项目，参与人员较多，并且等级划分严明，代码需要逐级审核的项目
仅核心开发人员可以向仓库推送代码，开发人员只能从仓库拉取代码，开发人员的代码需先推送给核心开发人员审核通过后，合并之后才能推送，一般情况下是使用GitHub的Pull Request的方式
正常的迭代开发流程
- 需求准备 当接收到正常的业务需求时，需要约定一个大的发布版本（一次迭代）以及这个发布版本包含的多个禅道任务，一个发布版本必须在一个时间点上发布；如果禅道上的任务粒度太大，则需要拆分细化成更小的禅道子任务（工作量在1~2人日为准，最好控制在一天以内）。
- 开发人员开发 以develop为基准创建一个分支，分支名称为“feature-禅道编号-开发人员姓名全拼”，如“feature-ONC-21-lishaohua”，禅道任务ONC-21的所有开发工作都在feature-ONC-21-lishaohua分支上进行，所有开发过程的commit message需要填写具体的开发内容。
- 提交test环境供测试人员测试 开发及单元测试工作完成后创建merge request合并到develop分支，合并请求消息同样需要复制禅道的内容描述以及具体的开发内容。
- UAT 开发人员的自测工作基于合并后的develop分支代码进行，如果这个发布版本所有禅道任务全部自测通过后，scrum master基于测试通过的develop分支创建一个release分支，分支名称为“release-版本号”，如“release-ctrip1.0”，测试人员基于release分支进行测试。
- UAT阶段bug修改 测试人员继续在新建的release分支上进行回归测试和验证，如果存在bug直接在该分支修改并合并到develop分支；如果验证通过则准备生产上线，生产上线时将release代码合并到master分支，并打tag，tag名称为“tag-版本号”，从master打包上线。
线上紧急bug修复流程
- 当发现线上bug需要紧急修复时（开发人员需要确保bug修复已经在禅道录入），需要以master分支为基准创建一个hotfix分支，分支名称为“hotfix-禅道编号-开发人员姓名全拼”；
- 开发人员可以预先在develop分支提交代码并和测试人员完成测试.
- 最终bug修复代码仍需要直接在新建的hotfix分支上提交，commit message需要填写具体的开发内容。需要测试人员直接在hotfix分支测试,此测试需要Eric协助将修改发到pre环境测试.
- 测试通过后，开发人员同时请求合并到master分支和develop分支，合并请求消息同样需要复制禅道的任务描述以及具体的开发内容。
- 生产上线时将hotfix代码合并到master分支，并打tag，tag名称为“tag-版本号-禅道编号”，从master打包上线。
高优先级开发任务流程
- 如果在其他发布版本或迭代在开发中，而优先级更高的迭代需要同时进行，则需要特别注意。在创建feature分支时，要确保develop分支和master分支时一致的没有被未上线甚至未测试的代码污染过的，如果是则直接以develop分支为基准创建新的分支，命名规范如同正常的业务需求流程；如果develop分支上已经有其他未上线分支的代码且该分支代码上线优先级较低，则不能以develop分支为基准创建分支，需要以master分支为基准创建分支。
- 当更高优先级feature功能开发和自测完成后，需要上测试环境，这时，需要以master分支为基准创建一个release分支，release分支名称为“release-版本号”，所有较高优先级的feature分支合并到高优先级的release分支上，并在该分支进行测试。
- 即确保是本次上线内容后 上面的测试可以直接跨过test环境,在uat环境测试
- release分支测试通过后，合并到master分支准备上生产，同时release合并到develop分支；master分支生产上线后打tag，tag名称为“tag-版本号”。
gitlab分支与dev,test,uat,pre,prod环境的对应关系以及权限
- dev环境对应develop分支,相关开发人员都有权限,主要用于开发人员自测
- test环境对应develop分支,相关开发人员都有权限,主要用于测试人员测试,包含所有需要上线和不需要上线的内容
- uat环境对应release分支,是保护分支,由scrum master创建并执行相关开发人员发起的merge request.merge request只能包含本次需要上线的内容
- pre环境对应master分支和hotfix分支,是保护分支,有Eric/Zeng Zhou/Jason 执行scrum master发起的merge request.只在发布生产环境时执行
- prod环境对应tag,pre环境回归通过后,由Eric/Zeng Zhou/Jason创建tag
最后关于几点需要强调一下
- 长期的使用的分支有两个master分支和develop 分支，其他的辅助分支hotfix分支、feature分支以及release分支都是临时分支，其生命周期在合并到develop或master上之后就基本结束，所以大家要养成良好的习惯，在分支生命周期结束之后尽快删除掉，以免堆积太多的分支而导致混乱；
- 大家开发过程中要勤提交、勤合并，原则上一些方法级别、类级别或单元测试级别的修改可以发起一次提交，提交的commit message写明工作的内容，一个feature或bug的自测完成可以发起一次merge request，merge request的message内容要复制jira任务的描述以及具体的开发工作内容描述，切勿堆积很大的工作量才发起合并
命名规则
- 每次提交必须写明注释，如果是修复Bug，请加上Bug号
- 创建特性分支，名称要以f-开头，加上特性名
- 创建发布分支，名称要以r-开头，加上预发布版本号
- 创建Bug修复分支，名称要以b-开头，加上Bug号
- 创建标签，名称要以t-开头，加上发布版本号
- 合并分支时必须使用--no-ff参数（禁止以快进方式合并），以保留合并历史轨迹
gitlab项目和权限管理
以下内容有Eric完成,不再赘述
- 项目创建
- 分组创建
- 项目创建
- 添加成员和设置权限
git常用命令
从svn迁移到git
安装git和tortoisegit
导出svn log到git
git svn clone [svn url] --no-metadata -A
例如
git svn clone https://cnbejtaxapp03.atrapa.deloitte.com/svn/源代码管理/DrTaxPlatform/trunk/tax-basic --no-metadata -A
关联本地git到远程git
