Git代码提交规范：测试团队的协作圣经
Git代码提交规范：测试团队的协作圣经
代码提交就像写日记，规范的提交信息能让团队成员快速理解你做了什么。作为测试工程师，我们不仅要写好测试代码，更要让团队协作变得高效愉快！
约定式提交规范
遵循约定式提交规范，让每次提交都有意义：
# 提交格式：<类型>[可选的作用域]: <描述>
feat: 添加用户登录接口测试用例
fix: 修复支付流程测试中的断言错误
test: 增加商品搜索功能的边界测试
docs: 更新API测试文档Git基础配置：身份证明
配置用户信息
# 设置全局用户信息
$ git config --global user.name="真实姓名"
$ git config --global user.email="公司邮箱"
# 💡 测试工程师小贴士：
# 正确的用户信息有助于代码审查和问题追踪user.email
使用公司邮箱，禁止使用个人邮箱。
user.name
使用个人真实姓名，禁止使用代号、昵称等。
- 可以使用中文全名，或中文全名拼音。
- 可以使用英文名。
- 有重名时，建议与邮箱保持一致。
分支与协作
分支命名
- 分支命名，要做到见名知意，避免无意义的命名，如 temp、aaaa、bugfix（bugfix-IssueABC 更佳）。
- 常见的 git workflow 分支模型包含 master、develop、feature、release、hotfix 等主干分支，命名应避免和主干分支冲突，引起歧义。
协作分支模型
以下内容规范多人协作时的分支命名与工作流。
单线（个人分支）
完全属于个人的内容或单人任务（需求、bugfix或其他工作不涉及协作），分支以个人名字进行分组，个人名字定义参考 config 中 user.name。以 Tony 同学开发购物车（shopping cart）功能或修复购物车问题为例：
tony/：个人分支分组
开发购物车功能的个人 feature 分支
tony/feature-shopping-cart
修复购物车问题的 bugfix 分支
tony/bugfix-shopping-cart-issuefoo
个人其他工作
tony/foo【推荐】在上述基础上，推荐个人分支也按照 feature 与 bugfix 等逻辑进行分组，如：
tony/：个人分支分组
开发购物车功能的个人 feature 分支
tony/feature/shopping-cart
修复购物车问题的 bugfix 分支
tony/bugfix/shopping-cart-issuefoo
个人其他工作
tony/foo协同（协作分支）
当需要多人协作完成某项任务或功能时，协作的同学需要自己建立用于协作的“主干”分支。协作的“主干”分支以 feature 进行分组。以购物车（shopping cart）为例：
feature/：协作分支分组
需要多人协作完成的购物车功能的协作“主干”分支
feature/shopping-cart如果是多人协作修复 Bug，则以 bugifx 进行分组：
bugifx/：协作分支分组
需要多人协作修复 issuefoo 问题的协作“主干”分支
bugifx/shopping-cart-issuefoo【推荐】协作时的个人分支，建议以个人名字+协作“主干”类型进行分组。例如：
Tony 和韩梅梅同学一起开发购物车功能
协作“主干”
feature/shopping-cart
Tony 同学
tony/feature/sc-tony-work
韩梅梅同学
hanmeimei/feature/sc-han-work
Tony 和韩梅梅同学一起修复购物车 issuefoo 问题
协作“主干”
bugifx/shopping-cart-issuefoo
Tony 同学
tony/bugifx/sc-issuefoo-tony-work
韩梅梅同学
hanmeimei/bugifx/sc-issuefoo-han-work
关于 MBox 创建分支：
如果使用 MBox 创建个人分支，可以使用 --prefix 选项覆盖默认的 feature 分组，例如：
mbox feature start --prefix=tony/feature sc-tony-work
mbox feature start --prefix=tony/bugifx sc-issuefoo-tony-work【推荐】协作分支功能开发稳定后，再提交合并到上游主干（通常 develop 或者专项主干）。 同理，个人分支应有阶段性成功后，再提交到协作主干。
【推荐】向协作主干进行提交时，推荐走 MR 相互进行 Review，将合入大主干的 Review 前置。避免大模块提交合并时， MR 代码过于集中代码量过大，Review 效率低的问题。
Merge 与 Rebase
https://blog.theodo.com/2018/09/keep-git-history-clean-using-rebase/)
【推荐】rebase 代替 merge
合并分支时，只有 Fast-Forward 的才能采用 merge 的方式进行合并，否则应使用 rebase，确保时间轴的单一性。（注意：对于已经 merge 过的分支，不要使用 rebase，rebase 会改变原有历史，导致commit 错乱，以至于其他协作者无法正常拉取更新）
场景1：我的本地分支需要合并主干的更新
本地分支开发一段时间之后，需要将主干的更新合并过来，用 rebase 代替 merge
$ git checkout your-work
$ git rebase develop
handle conflicts：
$ git add your change
$ git rebase --continue（git rebase --abort）注意：使用 git rebase -i，减少不必要的 commit。
$ git checkout your-work
$ git rebase -i develop
handle conflicts：
$ git add your change
$ git rebase --continue（git rebase --abort）Tips：合并主干之前建议先按 commit 原子性进行 squash commits，来减少 rebase 解决冲突的过程。
场景2：我的本地分支开发完毕了，需要提交 MR 到主干
此时不要直接提交 MR，应该先以 rebase 的方式（场景1）合并主干的更新，再提交 MR。
$ git checkout your-work
$ git rebase develop
handle conflicts：
$ git add your change
$ git rebase --continue（git rebase --abort）
$ git push origin your-work【推荐】git pull --rebase
git pull 默认以 merge 的方式进行合并。同样，以 rebase 的方式进行 pull 利于保持提交历史的线性。
场景：你与其他同学一起协作，建立了一个协作分支 cooperation，你们都直接在 cooperation 分支进行开发。
你在本地提交了改动，当你需拉取 cooperation 分支上的更新，git pull 时加上 --rebase 选项：
On branch cooperation
$ git pull --rebase
handle conflicts：
$ git add your change
$ git rebase --continue（git rebase --abort）
$ git push origin cooperation【推荐】当你不确定是否可以 Fast-Forward 时，可以使用 --ff-only 选项强制检查
On branch cooperation
$ git pull --ff-only