测试部 Git 使用规范
Version: 1.0
Writer: Shengjie
Date: 2020/3/6
前言
代码版本管理工具在多人协作的场景下有着非常重要的作用，此使用规范的编写旨在解决以下问题：
- 多人共同维护一个仓库时的代码冲突问题；
- 针对不同版本的软件测试时，测试代码的兼容性问题；
- 代码提交记录的可读性问题等。
多人共同维护一个仓库时的代码冲突问题
首先，确定仓库里现在的几个分支的作用，以 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
......