Git使用操作规范
一、创建自己的开发分支
1.1 配置Git环境
1.1.1 Windows平台上安装
1.1.2 Linux平台上安装
1.1.3 Mac平台上安装
1.1.4 基本概念名词解释
-
Git 工作区、暂存区和版本库
-
**工作区：**就是你在电脑里能看到的目录。
-
**暂存区：**英文叫 stage 或 index。一般存放在 .git 目录下的 index 文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。
-
**版本库：**工作区有一个隐藏目录 .git，这个不算工作区，而是 Git 的版本库。
-
1.2 添加本机sshkey到gitlab（可选）
1.3 克隆远程仓库中文件到本地
克隆一定要遵守Git开发规范，严禁克隆master分支。git clone 命令只用于第一次创建工程使用.
1.3.1 命令格式
克隆仓库的命令格式为：
git clone -b
如果我们需要克隆到指定的目录，可以使用以下命令格式：
git clone -b
参数说明：
- **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 可以省略。
( ): // 空一行 // 空一行
不管是哪一个部分，任何一行都不要有太多字符。这是为了避免自动换行影响美观。
**Header：**Header部分只有一行，包括三个字段：type（必填）、scope（影响范围，选填）和subject（必填）。
**Body：**Body 部分是对本次 commit 的详细描述，可以分成多行，每行尽量不超过72个字符。
**Footer：**Footer 部分只用于两种情况，不兼容变动、关闭Issue。
2.2.2 规范格式:
( ): # 例如： git commit -m "docs:update README.md"
Type： 必选项，用于描述本次commit更改类型，只允许使用下列7个标识，类型后使用英文冒号+空格:。
-
推荐：同类型多个内容以逗号,分隔，不同类型的提交内容可通过'; '格式进行区分提交（建议按照同一类型进行多次提交）。
示例：
单个类型提交：feat: 新增登录、注册、账号查询功能,新增密码修改功能
多个类型提交：feat: 新增登录功能；fix: 修复登录异常bug
序号 类型 说明 1 feat 新功能 2 fix 修补bug 3 docs 修改文档 4 style 格式化代码结构，没有逻辑上的代码修改 5 refactor 重构，即不是新增功能，也不是修改bug的代码变动，比如重命名变量 6 test 增加测试代码，单元测试一类的，没有生产代码的变更 7 chore 构建过程或辅助工具的变动（不会影响代码运行） -
**Scope：**可选项，用于描述程序开发影响的范围，比如数据层，控制层，视图层等等。示例描述词汇： Init，runner，watcher， config，web-server，proxy，etc等等，没有标准的描述标识。
-
**Subject：**必选项，是对commit的简短描述，不超过50个字符。以动词开头，使用第一人称现在时，第一个字母小写、结尾不加句号（中英文都不可以）。
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请求须有对应的项目管理员审核后才能成功。