# Git 规范
# 分支提交人修改
git config --global user.name "花名"
git config --global user.email "邮件地址"
# 分支管理
# 分支命名
- 需求：feature/开发人员_需求编号_需求简写
- 缺陷：hotfix/开发人员_缺陷编号_缺陷简写
# 常用分支
# 生产分支（master）
master 分支是仓库的主分支，也有人叫 production 分支，这个分支包含最近发布到生产环境的代码，最近发布的release， 这个分支只能从其他分支合并，不能在这个分支直接修改
master 分支一般由 UAT 以及 hotfix 分支合并，任何时间都不能直接修改代码
# 补丁分支（hotfix）
当我们在生产环境发现新的 Bug 时候，我们需要基于master分支创建一个hotfix分支，然后在hotfix分支上修复bug
# 功能分支（feature）
feature分支主要是用来开发一个新的功能，一旦开发完成，然后提交合并请求到 test 分支进行提测，测试通过后，按照迭代节奏合并当期 uat 分支进行发布准备
# Commit 规范
Commit messages提交可以参照以下格式
<type>: <subject>
<BLANK LINE> 空白行
<body>
<BLANK LINE> 空白行
<footer>
• type: 本次 commit 的类型，诸如 bugfix docs style 等
2
3
4
5
6
• scope: 本次 commit 波及的范围
• subject: 简明扼要的阐述下本次 commit 的主旨, 使用祈使句, . 首字母不要大写 . 结尾无需添加标点
• body: 同样使用祈使句，在主体内容中我们需要把本次 commit 详细的描述一下，比如此次变更的动机，如需换行，则使用 |
• footer: 描述下与之关联的 issue 或 break change
# Commit Type的类别
• feat: 添加新特性
• fix: 修复bug
• docs: 仅仅修改了文档
• style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑
• refactor: 代码重构，没有加新功能或者修复bug
• perf: 增加代码进行性能测试
• test: 增加测试用例
• chore: 改变构建流程、或者增加依赖库、工具等
# Commit messages 格式要求
标题行：50个字符以内，描述主要变更内容
主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括:
• 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等
• 他如何解决这个问题? 具体描述解决问题的步骤
• 是否存在副作用、风险?
如果需要的化可以添加一个链接到issue地址或者其它文档
# 关于名词简称
• CR：Code Review. 请求代码审查。
• PR： pull request. 拉取请求，给其他项目提交代码。
• MR： merge request. 合并请求
• ACK：Acknowledgement. 承认，同意。表示接受代码的改动。
• TL;DR：Too Long; Didn't Read. 太长懒得看。常见于README文档。
• WIP：Work In Progress. 进展中，主要针对改动较多的 PR，可以先提交部分，标题或 Tag 加上 WIP，表示尚未完成，这样别人可以先 review 已提交的部分。
• RFC：Request For Comment. 请求进行讨论，表示认为某个想法很好，邀请大家一起讨论一下
# 关于 Code Review 流程规范
# 需求开发 (由需求开发者负责)
• 本地切到 master 分支， 拉取最新代码（相关命令如下，GUI工具操作自行查相关文档）
git branch #查看当前位于哪个分支，前面打星号即为当前分支
git checkout master #切换到master分支
git pull #拉取最新代码
2
3
4
• 从 master 分支拉取一个新的分支，命名规范为 feature/开发人员_需求编号_需求简写，如 feature/张三_001_登录功能
git checkout -b feature/lvdagun_001_user_login
• 编码、本地自测完之后，提交代码到远程仓库
git add . #添加所有修改的文件
git commit -m "feat: add user login" #提交代码
git push origin feature/lvdagun_001_user_login #提交到远程仓库
2
3
• 在gitlab项目目录提交MR，邀请对应 code reviewer 进行代码审查 (一般情况下为对应团队TL)
在项目主页面，依次点击左侧“Merge Requests”，“New merge request”，打开新建Merge请求页面
在新建Merge请求页面，选择merge的源分支，及目标分支，点击“Compare branches and continue”按钮进入对比与提交页面
在对比与提交页面，可以点击“Changes” tab查看本次修改，确认无误，点击“Submit merge request”按钮，提交merge请求
提交之后，将结果页面的浏览器地址发到团队TL，由TL进行code review
# 提交格式
# Code Review (由code reviewer负责)
负责代码Review的同事收到申请后，点击merge请求地址，打开页面，查看 “Changes”。这里可通过 “Inline” 单边查看，也可以通过“Side-by-side”两个版本对比查看
review完成后，若无问题，则可点击”Merge”按钮完成merge；若有问题，则可点击“Close merge request”按钮关闭该merge请求（也可以不关闭复用该merge请求），同时通知开发者进行相应调整，重新提交代码发起merge请求（如果之前没关闭merge请求，则刷新即可看到调整）。
• MR 审查通过后，合并测试分支，由测试人员进行测试，测试通过后，合并到 uat 分支，测试不通过，由开发人员继续修改代码，直到测试通过
git checkout test #切换到test分支
git pull #拉取最新代码
git merge feature/lvdagun_001_user_login #合并代码
git push origin test #提交到远程仓库
2
3
4