一、创建自己的开发分支
1.1 配置Git环境
1.1.1 Windows平台上安装
1.1.2 Linux平台上安装
1.1.3 Mac平台上安装
1.1.4 基本概念名词解释
-
Git 工作区、暂存区和版本库
1.2 添加本机sshkey到gitlab(可选)
1.3 克隆远程仓库中文件到本地
克隆一定要遵守Git开发规范,严禁克隆master分支。git clone 命令只用于第一次创建工程使用.
1.3.1 命令格式
克隆仓库的命令格式为:
git clone -b <branch> <url>
如果我们需要克隆到指定的目录,可以使用以下命令格式:
git clone -b <branch> <url> <directory>
参数说明:
- **branch:**分支的名称,严禁克隆master/main分支。
- **url:**Git 仓库地址。
- **directory:**本地目录,只有此目录不存在或者是空文件夹时,才允许克隆。
1.3.2 命令示例
# 从develop分支克隆项目文件到本地demo4文件夹 git clone -b develop http://10.10.10.100/chenchu/demo1.git demo4
1.3.3 创建本地分支
当develop分支克隆完成后,就应该按照您对分支的开发类型进行创建本地分支进行开发。
# 对克隆下来的项目进行本地新分支命名 git checkout -b feature/demo_readme
1.3.4 分支命名规范
功能分支以 feature/ 开头, 如 feature/download_module, feature/control_module;
修复bug分支以fix/ 开头,如 fix/login_module,fix/login_module。
此时,我们的开发环境已经就绪,可以进入开发环节。
二、开发分支的提交规范
2.1 commit message提交规范
团队开发中,遵循一个合理、清晰的Git使用流程,是非常重要的。否则,每个人都提交一堆杂乱无章的commit,项目很快就会变得难以协调和维护。当我们对一个功能开发到一个阶段需要进行commit操作的时候,commit message( 提交说明 )的提交需遵循描述规范,严禁随意描述。
2.1.1 Commit message 组成部分
每次提交,Commit message 都包括三个部分:Header,Body 和 Footer,其中,Header 是必需的,Body 和 Footer 可以省略。
<type>(<scope>): <subject> // 空一行 <body> // 空一行 <footer>
不管是哪一个部分,任何一行都不要有太多字符。这是为了避免自动换行影响美观。
**Header:**Header部分只有一行,包括三个字段:type(必填)、scope(影响范围,选填)和subject(必填)。
**Body:**Body 部分是对本次 commit 的详细描述,可以分成多行,每行尽量不超过72个字符。
**Footer:**Footer 部分只用于两种情况,不兼容变动、关闭Issue。
2.2.2 规范格式:
<type>(<scope>):<subject> # 例如: git commit -m "docs:update README.md"
Type: 必选项,用于描述本次commit更改类型,只允许使用下列7个标识,类型后使用英文冒号+空格:。
2.2.3 标准化Commit message的好处
- 提供更多的历史信息,方便快速浏览;
- 可以过滤某些commit(比如文档改动),便于快速查找信息;
- 可以直接从 commit 生成 Change log(Change Log 是发布新版本时,用来说明与上一个版本差异的文档)
2.2 分支的提交
2.2.1 查看当前所在分支
当我们不清楚自己分支名字的时候我们可以用git branch命令进行查看,带星号的就是当前分支。
git branch
2.2.2 Push本地开发分支到远程仓库
push之前一定要pull。
git pull branch_name
git push origin feature/demo_readme #Push本地开发分支到远程仓库
2.2.3 查看远程仓库分支
当我们成功使用push操作之后,我们将可以在GitLab上看到我们刚push上去的分支。
2.4 发起合并请求
当一个功能分支已经进入到开发完成的阶段,这时候我们就应该要发起与develop分支的合并请求了。
合并分支的流程:
2.4.1 登录 Gitlab 找到 Merge Request(合并请求)
2.4.2 新建合并请求
2.4.3 选择需要发起合并的分支
选择完成后点击Compare branches and continue。
在项目开发阶段,原则上,开发人员只允许选择发起合并到develop分支的请求。
未经项目负责人同意严禁对master分支发起合并请求。
2.4.4 添加对合并请求的描述,并发起合并请求
当我们点击 Compare branches and continue 后将会打开对发起合并请求的描述页面。
**Title **的描述将会显示在Merge Request的列表中,对于Title的描述填写应该做到简单明了,让审核人能迅速的读懂您的请求含义。
**Description **是对发起请求的详细描述,对于这个描述内容目前还没有标准的规范,但也应该做到描述思路清晰,不要添加和请求合并描述无关紧要的语句。
当我们将所有信息确认无误的填写完毕后,单击最页面最底下的 Create merge request( Create 合并请求 ) 用于提交分支请求。
2.4.5 关闭错误的合并请求
三、分支的管理与结构
- 自己的分支一定要自测,切记不要提交后,影响到其他代码,更别说别人拉下代码还报错这种低级错误;
- 本地分支要做到勤提交,分小功能提交,一次提交一大堆各种功能的做法也要杜绝;
- 每天第一件事就是更新 develop 分支内容到本地分支,避免大规模 merge,太容易出错了;
- 迭代新版本时,一定要保证当前开发分支和线上分支一样;
3.1 分支的结构
3.2 新分支的创建
当一个功能开发完毕并提交合并请求并成功合并之后并要进行下一阶段的开发工作时,我们应严格遵守开发规范,与develop分支同步后再进行开发。但不赞成使用git clone命令重新进行新建工作区来进行新功能的开发。对于下一个新功能的开发我们应该在原工作区使用以下命令进行操作:
3.3 设置默认分支
3.4 分支的保护
用户拥有不同的权限,具体取决于他们在特定组或项目中的角色。
系统中五种角色分别是:Guest -- Reporter -- Developer -- Maintainer -- Owner
3.3.1 角色权限
初始状态下,整个项目应该至少具备 main分支和develop分支,对于他们的权限和管理应遵循以下原则。详细的角色可以用权限请参考:Permissions · User · 帮助 · GitLab
3.3.2 分支的保护设置(适用于项目管理员)
受保护的分支为main和develop分支;
master分支的所有操作权限应该仅由项目管理员拥有;
而develop分支的只有merge权限可以开发给开发者,并且merge请求须有对应的项目管理员审核后才能成功。