Git协作规范

发表于 | 分类于
Git协作规范

前言

以下是一个Git 开发协作方案，适用于大多数团队的项目开发，涵盖了分支管理、代码提交、代码审查和合并等关键环节。

分支管理策略

采用 GitFlow 成熟的分支管理模型：

6ce9ff6c7a3e2b1e9781b4389f808c00

主要分支

  • master（主分支）：始终保持可用于生产环境的稳定代码，只接受从 release 或 hotfix 分支合并过来的代码。
  • develop（开发分支）：用于集成所有新功能和修复，是日常开发的基础分支。

辅助分支

  • feature（功能分支）：从 develop 分支派生，用于开发新功能。

    命名规则可以是 feature/[功能名称]，例如 feature/user-login。

  • release（预发布分支）：从 develop 分支派生，用于准备新的版本发布。在这个分支上进行最后的测试和小的修复。

    命名规则可以是 release/[版本号]，例如 release/1.0.0。

  • hotfix（紧急修复分支）：从 master 分支派生，用于紧急修复生产环境中的问题。

    命名规则可以是 hotfix/[问题描述]，例如 hotfix/login-bug。

标签

发版时预发布分支合并到到主分支，添加版本tag

1
2
git tag -a 1.0 -m "Release version 1.0"
git push origin --tags

开发流程

功能开发

  1. 创建功能分支：

    开发者从 develop 分支创建一个新的 feature 分支。

    1
    git checkout -b feature/user-login develop

如果开发人员要开发多个功能模块，可以根据人员建立分支

1
git checkout -b feature/zhangsan develop

  1. 进行开发：在 feature 分支上进行代码编写和测试。

  2. 提交代码：定期将代码提交到 feature 分支。

    1
    2
    git add .
    git commit -m "完成用户登录功能开发"

  3. 同步 develop 分支：在开发过程中，可能会有其他开发者向 develop 分支合并了新的代码，因此需要定期同步 develop 分支的更新。

    1
    2
    3
    4
    git checkout develop
    git pull origin develop
    git checkout feature/user-login
    git merge develop

  4. 推送代码：完成功能开发后，将 feature 分支推送到远程仓库。

    1
    git push origin feature/user-login

代码审查和合并

  1. 创建拉取请求（Pull Request，简称 PR）：在代码托管平台（如 GitHub、GitLab 等）上创建一个 PR，将 feature 分支合并到 develop 分支。在 PR 中详细描述本次开发的功能和修改内容。
  2. 代码审查：团队成员对 PR 中的代码进行审查，提出反馈和建议。开发者根据反馈进行修改，直到代码通过审查。
  3. 合并代码：代码通过审查后，将 feature 分支合并到 develop 分支，并删除 feature 分支。
    1
    2
    3
    4
    git checkout develop
    git merge feature/user-login
    git push origin develop
    git branch -d feature/user-login

版本发布

  1. 创建 release 分支：当 develop 分支上积累了足够的新功能和修复后，从 develop 分支创建一个 release 分支。

    1
    git checkout -b release/1.0.0 develop

  2. 进行最后的测试和修复：在 release 分支上进行全面的测试，修复发现的问题。

  3. 合并到 master 和 develop 分支：测试通过后，将 release 分支合并到 master 和 develop 分支，并在 master 分支上打标签。
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    git checkout master
    git merge release/1.0.0
    git tag -a v1.0.0 -m "版本 1.0.0 发布"
    git push origin master
    git push origin v1.0.0

    git checkout develop
    git merge release/1.0.0
    git push origin develop

    git branch -d release/1.0.0

紧急修复

  1. 创建 hotfix 分支：当生产环境出现紧急问题时，从 master 分支创建一个 hotfix 分支。

    1
    git checkout -b hotfix/login-bug master

  2. 修复问题：在 hotfix 分支上进行问题修复。

  3. 合并到 master 和 develop 分支：

    修复完成后，将 hotfix 分支合并到 master 和 develop 分支，并在 master 分支上打标签。

    删除热修复分支。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    git checkout master
    git merge hotfix/login-bug
    git tag -a v1.0.1 -m "修复登录问题"
    git push origin master
    git push origin v1.0.1

    git checkout develop
    git merge hotfix/login-bug
    git push origin develop

    git branch -d hotfix/login-bug

代码提交规范

  • 提交信息清晰：使用简洁明了的提交信息，描述本次提交的主要内容和目的。例如：feat: 新增用户登录功能、fix: 修复登录验证错误。
  • 小步提交：将大的功能开发拆分成多个小的提交，每个提交只包含一个明确的修改。这样可以方便代码审查和问题定位。

格式

1
<类型>: <简短描述>

类型说明

类型 描述
feat 新增功能（feature）
fix 修复 Bug
docs 文档更新（如 README、注释）
style 代码格式调整（不影响功能，如空格、分号修正）
refactor 代码重构（既不修复 bug 也不添加功能）
perf 性能优化
test 添加或修改测试用例
build 影响构建系统或外部依赖的修改（如 webpack、package.json）
ci CI 配置文件和脚本的修改（如 GitHub Actions、Jenkins 配置）
chore 其他杂项修改（如更新构建任务、辅助工具等）
revert 回滚之前的提交

示例

1
2
fix: 修复登录验证失败问题
feat: 添加用户头像上传功能

团队协作规范

  • 及时沟通：团队成员之间保持良好的沟通，及时交流开发进度、遇到的问题和解决方案。
  • 遵循代码风格：团队统一代码风格和规范，提高代码的可读性和可维护性。
  • 定期同步：定期同步代码，避免代码冲突和合并问题。

同步时间

  • 每天早上进行代码合并。
  • 临时沟通合并。

工具和平台

  • 代码托管平台：选择合适的代码托管平台，方便团队成员协作和代码管理。
  • 代码审查工具：利用代码托管平台提供的代码审查功能，或者使用专门的代码审查工具，如 Review Board 等，进行代码审查。
  • 代码质量工具：Sonar的主要功能是对代码进行全面的质量分析，它可以检测代码中的各种问题，如代码异味（Code Smells）、漏洞、潜在的错误等，并提供详细的分析报告。
  • 持续集成/持续部署（CI/CD）工具：使用 CI/CD 工具，如 Jenkins、GitLab CI/CD、CircleCI 等，自动化代码构建、测试和部署过程，提高开发效率和质量。