跳到主要内容

代码提交

介绍​

我们公司大部分项目采用『Git』与『GitLab』进行版本管理，推荐阅读官方『Pro Git』文档进行一些基础命令学习。

一般而言，我们的项目会有多为开发人员参与代码提交，也会在多个分支进行开发，一个良好的分支管理与代码提交规范有利于代码仓库的管理维护与项目的开发。

代码分支管理​

我们通常会在多个分支上进行开发，并设有部分分支满足部署与项目发布等目的。我们通常建议分为长期分支与短期分支两类，并根据目的进一步细分：

  • 长期分支
    • master 主分支
    • develop 开发分支
  • 短期分支
    • feature 功能分支
      • develop -> feature -> develop
    • fix 修复分支
      • develop -> fix -> develop
    • release 预发布分支
      • develop -> release -> master & develop
    • hotfix 补丁分支
      • master -> hotfix -> master & develop

我们的 master 分支通常只有项目负责人才可以提交代码，作为阶段性项目稳定版本发布，须确保 master 分支的代码经过各类测试且始终处于可编译部署状态。

而 Develop 分支为主要的开发分支，通常用于开发新功能、修改已有功能、或者对已有功能进行测试。通常开发人员不会之间将代码提交至该分支，而是通过 Merge Requests 进行代码合并请求，经过一些自动化检测无误后，项目负责人或对应代码审查人员经检查与反馈修改后，合并至分支，并通过 CI/CD 部署线上版本，便于线上环境功能调试。

而短期分支主要分为 feature、fix、release 与 hotfix 四种类型，其中 feature 分支用于开发/修改新功能，release 分支用于预发布，hotfix 分支用于对已发布版本打补丁。

开发人员主要在自己的 feature 或 fix 分支进行开发，完成对应的开发工作后提交 Merge Requests 至 develop 分支；而对应项目负责人员则需要对 release 与 hotfix 分支进行严格管理，确保代码调试无误后提交至 master 或 develop 分支进行版本发布或热修复。

需要注意的是，开发人员在自己的对应分支工作时，需要养成多从 develop 分支拉取最新代码并解决冲突的习惯，以免后期与其他开发人员的提交产生较多冲突，有较大的工作量。

代码提交频率​

我们建议每次代码提交都为小且目的单一的提交，如新增一个 feature、修复一个 bug 或修改部分说明文档等，尽量不要一次性提交过多代码或一次提交中涉及多个目的，这样容易与其他协同开发人员产生代码冲突，也不利于代码审查，容易产生一些潜在 bug。

代码提交规范​

我们每次代码提交需要以简短明确的提交内容来描述本次变化的类型、影响范围、细节描述等。我们常用的提交包括：

  • feat: 一个新 feature
  • fix: 一个 bug 修复
  • docs: 文档修改
  • style: 代码风格修改
  • refactor: 代码重构
  • perf: 性能优化
  • test: 新增或修改测试
  • build: 构建相关脚本或配置修改
  • ci: CI/CD 相关脚本或配置修改
  • chore: 与源码或测试无关的其他修改
  • revert: 回滚到之前的版本

我们一般采用 <提交类型>: <描述> 的方式进行提交。当然，每次手动填入会比较麻烦，也容易出错，主流 IDE、编辑器与命令行都提供了一些工具与插件来辅助我们填写提交信息，如你使用的是 Jetbrains 系列 IDE，可以安装插件『Git Commit Template』，具体使用可参看说明。如果你习惯使用命令行进行提交，可以下载『cz-cli』工具，根据说明安装在你的开发环境。之后的提交就可以使用 git cz 命令进行交互式提交，其他编辑器也有类似工具，可自行探索并使用自己最熟悉的方式。

当我们形成了结构化的提交历史，可以借助『git-chglog』工具生成 CHANGELOG.md 文档，便于版本发布与迭代。例如，我们需要发布一个 tag 为 v1.0.0 的版本，可以在项目目录运行下述命令自动生成：

git-chglog --init
git-chglog -o CHANGELOG.md --next-tag v1.0.0

代码审查规范​

开发人员合并到 develop 分支前需要通过 gitlab ci 进行检测，我们通常会包含代码静态检查与代码缺陷检查两部分，gitlab ci 检测通过后负责人进行代码审查，手动合并。

代码静态检查​

在 Go 语言项目中，我们通常使用 staticcheck 命令行工具进行静态检查，可以根据文档安装使用并预先进行本地检查。

go install honnef.co/go/tools/cmd/staticcheck@latest

通常在项目根目录运行如下命令可以对所有代码进行检查：

staticcheck ./...

代码缺陷检查​

我们通常会使用 sonarqube 开源工具进行代码质量与缺陷检查，我们也提供了 sonarqube 配置教程 - SonarQube 代码质量检查工具配置。

在 Merge Requests 提交后 gitlab ci 会自动运行，但通常来说 sonarqube 所检测出的问题可后期再修复。