Skip to main content

Git 使用标准（人类）

本文面向人类开发者，强调日常协作中最容易出错的操作与最低可执行标准。

1. 分支命名规则​

  • develop：开发主干，最不稳定的分支（有可能有很多刚开发完的功能会陆陆续续的往里面合并）
  • master：开发周期中的中间分支，每个版本结束之后，会用develop同步到这个分支（这只是原有想法，暂时没怎么用上）
  • release：线上分支，这个分支永远对标是的是线上用户跑的版本，只有当预发布分支正式发布之后，才会把预发布分支同步到这个分支。
  • 预发布分支：用release创建的分支，这个分支意味着将要准备发布内部到线上。
    • 命名约定
      • 小更新：release-日期
      • 送审包：release-review-日期
  • 个人分支：顾名思义，不多解释。
    • 命名约定：个人名字简写/目标分支/分支改动描述，例如czy/develop/bufig-task

2. 常用Git操作​

  1. 从最新主线拉取分支（Pull）
  • 解决冲突：1. 不能参考svn的解决操作。 2. 不懂或者不熟，最好让别人或者AI指点一下。
  1. 基于目标分支创建你的分支(Create Branch)
  2. 提交改动（Commit）
  3. 推送（Push）
  4. 创建 MR（合并请求）

3. 提交信息规范​

正常来说个人分支不需要太多的要求，因为都需要申请 MR（合并请求），MR的要求下面会说。

4. MR（合并请求）要求​

  • 勾上 Remove source branch。（重新创建分支没那么麻烦，用已经合并的老分支导致造成冲突才麻烦）
  • 勾上 Squash commits。
  • 标题一定要写，并且是这次改动的简要。（查看提交记录主要是看这个标题）
    • 标题最好能带上平台单子的id，例如 PROJECT2-949，这样方便回溯
  • 内容可以不填，看实际情况。

5. 合并前检查​

  • 代码/配置与当前需求匹配
  • 无未提交临时文件（本地日志、调试脚本、构建产物）
  • 与最新主线无明显冲突

6. 禁止项​

  • 未经评审直接合并主线
  • 强制重写共享分支历史（--force）
  • 在提交中混入大量无关文件
  • 在代码中硬编码密钥、token、账号或路径信息

7. 冲突与回退​

  • 处理冲突时先解决最小范围，保证功能不退化。
  • 不能确认影响时，不要直接推进，先同步评审人或负责人。
  • 回退前确保有：
    • 回退点（commit/hash）
    • 回退影响范围说明
    • 验证命令

8. 经验化建议（新手高频踩坑）​

  • 每次只改一个独立问题，避免一次提交包含 5+ 功能点