Git代码管理规范

来自ling
跳转至: 导航搜索

常用链接

ssh-key-pair

https://cnbejtaxsql01

git config --system http.sslverify false

本次迁移范围

只包含源代码,不包括文档

GitLib有五种身份权限 (项目创建,用户注册,权限开通请联系Eric)

  • Owner 项目所有者,拥有所有的操作权限
  • Master 项目的管理者,除更改、删除项目元信息外其它操作均可
  • Developer 项目的开发人员,做一些开发工作,对受保护内容无权限
  • Reporter 项目的报告者,只有项目的读权限,可以创建代码片断
  • Guest 项目的游客,只能提交问题和评论内容

分支使用的规则

本规范用于描述日常研发流程中关于GitLab上代码分支使用的规则,大家共同严格遵守规范,避免出现分支管理混乱现象,保证日常的发版上线工作顺利进行。

  • Workspace:工作区,平时我们写代码的地方。
  • Index:暂存区,写完代码后让它变成的待提交的状态。
  • Repository:本地仓库,提交暂存区的代码到这里,记录进入代码本地管理。
  • Remote:远程仓库,将本地仓库的修改的代码提交到远程,可以供远程协作的人下载。

分支管理规范主要遵循gitflow的分支管理流程,见下图: Git flow.PNG

分支定义

常规代码管理流程如下

Git code flow.png

主要分支(保护分支)

master分支

  • 只存线上的代码,只有确定可以上线时的才合并到master上,并且在master的基础上打Tag。
  • master 主分支,稳定代码,为生产环境做准备的

develop分支

  • develop 开发分支,为开发服务
  • 初次创建develop时,需要从master分支拉取,保持开发时代码和线上最新的代码相同。develop分支是在开发时的最终分支,具有所有当前版本需要上线的所有功能。

Git master develop.png

辅助分支

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分支推送到远程仓库

Git feature branches.png

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 hotfix.png

Git协同模型

SVN式集中协同模型

适用于小型项目,参与人员较少的项目,每个开发者均可向仓库推送代码

Git svn-like.png

金字塔模型

适用于大型项目,参与人员较多,并且等级划分严明,代码需要逐级审核的项目

仅核心开发人员可以向仓库推送代码,开发人员只能从仓库拉取代码,开发人员的代码需先推送给核心开发人员审核通过后,合并之后才能推送,一般情况下是使用GitHub的Pull Request的方式

Git pyramid.png

正常的迭代开发流程

  • 需求准备 当接收到正常的业务需求时,需要约定一个大的发布版本(一次迭代)以及这个发布版本包含的多个禅道任务,一个发布版本必须在一个时间点上发布;如果禅道上的任务粒度太大,则需要拆分细化成更小的禅道子任务(工作量在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常用命令

Git command.jpeg

从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

Git01.PNG Git02.PNG

push代码到远程git

参考Tax_gitlab管理#push 源代码

参考链接

https://juejin.im/post/5c613dadf265da2de450545e

https://www.zybuluo.com/zhanggang807/note/83152