选择一个工作流
git flow
推荐使用 Git flow 来协调我们的提交工作，这个工作流比较普适，在我们没有特殊的需求之前，可以采用这个工作流，具体可百度查阅详情。
如需 code review，可在 gitlab 上将 develop 分支设置为受保护的，需要 merge request approved 之后才能合并到 develop 分支。
commit message
为提高代码审核者的可读性，提交代码的时候，commit message前缀建议:
- feat：新功能（feature）
- func：小粒度的功能点提交
- fix：修补bug
- docs：文档（documentation）
- style： 格式（不影响代码运行的变动）
- refactor：重构（即不是新增功能，也不是修改bug的代码变动）
- test：增加测试
- chore：构建过程或辅助工具的变动
commit message 示例：
| ``` git commit -m "fix: 修复某个bug"
| ------------------------------------ |
\
### git tag
`master` 分支为稳定的生产分支，测试分支的代码经过QA验证通过之后，需要合并到 master 分支；建议在代码测试好后，合并之前，为当前测试通过的 commit 打上tag，然后合并到 master。
git tag 示例：
| ```
git tag -a v2.3 -m "Release v2.3" git push origin --tags
``` |
| ----------------------------------------------------------------- |
\
## 版本号
版本号是我们更新和发布一个版本的基础，如果发布出现问题，也便于回滚。
\
### 如何生成
根据Git的提交记录，我们使用如下命令就能生成版本号：
Shell
| ```
git describe --abbrev=4 --dirty --always --tag
``` |
| ------------------------------------------------------ |
使用Python
| ```
from subprocess import check_output git_version = check_output("git describe --abbrev=4 --dirty --always --tags".split()).decode('utf-8').strip()
``` |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
\
### 生成规则
根据是否打过tag，是否有提交记录，生成的版本号各有差异，具体生成的版本号格式由如下元素组成：{最近一个tag}-{距离上个tag多少个提交}-{commit id的最开始4个字符} ，比如下例子：
| ```
v1.2.8-292-gfe6c
``` |
| ------------------------ |
\
\
如果提交历史上都没有打过 tag，那么生成的版本号只是最近 commit id 串的前4，,如：
| ```
fe6c
``` |
| ------------ |
\
\
如果打过tag，后面没有提交，那么生成的版本号如下：
| ```
v1.2.8
``` |
| -------------- |
\
\
### 容器镜像版本
完整镜像名的组成：`REGISTRY[:PORT]/USER/REPO[:TAG]` ，注意TAG部分，我们打成的容器TAG使用的是上文中的方式生成的版本号，并且在最前面还加上了jenkins 打包的 `${BUILD_ID}`。最终生成的完整镜像名如下：
| ```
registry.cn-shanghai.aliyuncs.com/gemii/liz-qywechat-open:11-v1.2.8-291-gfdd85
``` |
| -------------------------------------------------------------------------------------- |
\
这是使用阿里云的镜像仓库之后的完整的镜像名地址，使用阿里云仓库的好处是能完美地和阿里云的kubernetes服务集成。阿里云的镜像仓库的名字组成格式为：`{registry}/{namespace}/{仓库}:{标签}` 。
\
## 其他最佳实践
\
### 如何让git commit历史更清爽
使用rebase可以让develop分支的提交历史更干净（成线性），原理可参考 [这个文章](https://www.jianshu.com/p/6960811ac89c) ，参考操作步骤记录如下：
| ```
# 从 develop 新开分支开始开发 git checkout develop git pull git checkout -b feature/foo # 多次提交完成开发任务 git add . git commit -m "feat: 完成需求foo" # 合并本地的提交记录 --- 2表示合并两个 git rebase -i HEAD~2 # rebase 之前将 develop 分支拉到最新 git checkout develop git pull git checkout feature/foo # 有冲突就解决冲突，解决后直接git add . 再git rebase --continue即可 git rebase develop # merge 回 develop 分支 git checkout develop git merge feature/foo # 推送到远程 git push origin develop
``` |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
\
