【Git】测试部Git使用规范

测试部 Git 使用规范

Version: 1.0

Writer: Shengjie

Date: 2020/3/6

前言

代码版本管理工具在多人协作的场景下有着非常重要的作用，此使用规范的编写旨在解决以下问题：

1. 多人共同维护一个仓库时的代码冲突问题；
2. 针对不同版本的软件测试时，测试代码的兼容性问题；
3. 代码提交记录的可读性问题等。

多人共同维护一个仓库时的代码冲突问题

首先，确定仓库里现在的几个分支的作用，以 Repo_Test 为例：

master // 主分支，能够稳定运行测试代码的分支，用于主版本测试 Commiter: All tester
daily_test // 每日构建分支，用于每日自动测试 Tengine develop 分支，供研发使用。只要确保能跑就行。Commiter: Shengjie

当需要修改代码时，先从最新的 master 分支切出一个分支来，然后在新分支上开发，测试通过后再合入主分支。

新分支的命名规则如下：

type/short description
=========举例如下========
feature/add_new_case
fix/type_error

切换分支的命令：

master // current branch
git checkout -b feature/add_new_case // create and checkout to feature/add_new_case from the master branch

合入主分支的命令：

master // current branch
git merge feature/add_new_case // merge feature/add_new_case to the master branch

针对不同版本的软件测试时，测试代码的兼容性问题

通过分支管理来进行不同的版本测试。比如说以下三种情况：

• 内部版本, eg. 1.10, 1.11, 1.12 可以通过创建分支 version/1.11, version/1.12 进行测试

• 交付版本, eg. 客户A, 客户B可以通过创建分支 deliver/kha, deliver/khb 进行测试

• 开源版本, eg. 1.11开源, 1.12开源 可以通过创建分支 open/1.11, open/1.12 进行测试

分支命名的格式如下：

内部版本 version/<version number>
交付版本 deliver/<companyName_versionNumber>
开源版本 open/<version number>

在每个版本测试完成后，以上分支进行保留，以便今后版本回溯及复用。

代码提交记录的可读性问题等

不管是在哪个分支，代码更新后提交时会要求填写一个 commit messege, 这个信息主要用于简述当次代码提交的作用。为使阅读代码的人清楚所提交代码的作用，要求提交信息填写如下：

[type]:short description
=========举例如下==========
[fix]:fix bug
[feature]:new feature
[refactor]:refactor code
[docs]:modify docs

除了以上分支和提交信息的要求，还有一些 git 的有用命令列出如下：

// scene: when fix bug in master branch, need merge to another branch
git cherry-pick <commit id>
// scene: revocation latest commit
git reset --soft HEAD~ // revocation commit and save the local modify
git reset --hard HEAD~ // revocation commit and discard the local modify
......