ogt-docs-rules-git

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

OGT Docs - Rules Git

OGT 文档 - Git规则

Complete guide for creating and managing Git workflow rules.
创建和管理Git工作流规则的完整指南。

Overview

概述

Git rules establish consistent version control practices. They cover commit messages, branch naming, pull request requirements, and code review standards.
mermaid
flowchart TB
    subgraph git ["docs/rules/git/"]
        C["commits/"]
        B["branches/"]
        P["pull_requests/"]
        R["reviews/"]
        M["merging/"]
        T["tags/"]
    end

    C --> |format| CM["Conventional Commits"]
    B --> |naming| BN["Branch Patterns"]
    P --> |requirements| PR["PR Templates"]
    R --> |standards| RS["Review Checklists"]
Git规则用于建立一致的版本控制实践,涵盖提交消息、分支命名、拉取请求(PR)要求以及代码评审标准。
mermaid
flowchart TB
    subgraph git ["docs/rules/git/"]
        C["commits/"]
        B["branches/"]
        P["pull_requests/"]
        R["reviews/"]
        M["merging/"]
        T["tags/"]
    end

    C --> |format| CM["Conventional Commits"]
    B --> |naming| BN["Branch Patterns"]
    P --> |requirements| PR["PR Templates"]
    R --> |standards| RS["Review Checklists"]

When to Use

适用场景

  • Establishing commit message conventions
  • Defining branch naming patterns
  • Setting PR requirements and templates
  • Creating code review standards
  • Defining merge strategies
  • Setting up release tagging
  • 制定提交消息规范
  • 定义分支命名模式
  • 设置PR要求与模板
  • 创建代码评审标准
  • 定义合并策略
  • 配置发布标签规则

Folder Structure

目录结构

docs/rules/git/
├── commits/                        # Commit message rules
│   ├── rule.md
│   ├── examples.md
│   ├── .version
│   └── .enforced_by
├── branches/                       # Branch naming rules
│   ├── rule.md
│   ├── examples.md
│   └── .enforced_by
├── pull_requests/                  # PR requirements
│   ├── rule.md
│   ├── template.md                 # PR template
│   ├── examples.md
│   └── .enforced_by
├── reviews/                        # Code review standards
│   ├── rule.md
│   ├── checklist.md               # Review checklist
│   └── examples.md
├── merging/                        # Merge strategy rules
│   ├── rule.md
│   └── examples.md
└── tags/                           # Release tagging rules
    ├── rule.md
    └── examples.md

docs/rules/git/
├── commits/                        # 提交消息规则
│   ├── rule.md
│   ├── examples.md
│   ├── .version
│   └── .enforced_by
├── branches/                       # 分支命名规则
│   ├── rule.md
│   ├── examples.md
│   └── .enforced_by
├── pull_requests/                  # PR要求
│   ├── rule.md
│   ├── template.md                 # PR模板
│   ├── examples.md
│   └── .enforced_by
├── reviews/                        # 代码评审标准
│   ├── rule.md
│   ├── checklist.md               # 评审检查清单
│   └── examples.md
├── merging/                        # 合并策略规则
│   ├── rule.md
│   └── examples.md
└── tags/                           # 发布标签规则
    ├── rule.md
    └── examples.md

Example: docs/rules/git/commits/

示例:docs/rules/git/commits/

Commit message format rules.
提交消息格式规则。

Folder Structure

目录结构

docs/rules/git/commits/
├── rule.md
├── examples.md
├── .version
└── .enforced_by
docs/rules/git/commits/
├── rule.md
├── examples.md
├── .version
└── .enforced_by

rule.md

rule.md

markdown
undefined
markdown
undefined

Rule: Commit Message Format

规则:提交消息格式

Summary

概述

All commit messages MUST follow Conventional Commits format.
所有提交消息必须遵循Conventional Commits格式。

Rationale

设计理由

Consistent commit messages enable:
  • Automated changelog generation
  • Semantic versioning automation
  • Easy history navigation
  • Clear communication of changes
一致的提交消息可实现:
  • 自动生成变更日志
  • 语义化版本自动化
  • 便捷的历史记录导航
  • 清晰的变更沟通

The Rule

规则详情

Format

格式


<type>(<scope>): <description>

[optional body]

[optional footer(s)]

<type>(<scope>): <description>

[可选正文]

[可选页脚]

Types

类型

TypeUse When
feat
New feature
fix
Bug fix
docs
Documentation only
style
Formatting, no code change
refactor
Neither fixes nor adds feature
perf
Performance improvement
test
Adding/updating tests
chore
Maintenance tasks
ci
CI/CD changes
build
Build system changes
类型使用场景
feat
新功能
fix
Bug修复
docs
仅文档更新
style
格式调整,无代码逻辑变更
refactor
既不是修复也不是新增功能的重构
perf
性能优化
test
添加/更新测试
chore
维护任务
ci
CI/CD流程变更
build
构建系统变更

Requirements

要求

  1. MUST use lowercase type
  2. MUST use imperative mood ("add" not "added")
  3. MUST limit first line to 72 characters
  4. SHOULD include scope for clarity
  5. MUST reference issue number for bug fixes
  6. MUST mark breaking changes with
    !
    or footer
  1. 必须使用小写类型
  2. 必须使用祈使语气(如"add"而非"added")
  3. 必须限制首行长度不超过72个字符
  4. 建议包含作用域以提升清晰度
  5. 必须在Bug修复中引用问题编号
  6. 必须通过
    !
    或页脚标记破坏性变更

Breaking Changes

破坏性变更

Two ways to indicate breaking changes:

feat(api)!: change auth header format
Or:

feat(api): change auth header format

BREAKING CHANGE: Authorization header now requires "Bearer " prefix
标记破坏性变更的两种方式:

feat(api)!: 修改认证头格式
或:

feat(api): 修改认证头格式

BREAKING CHANGE: 认证头现在需要添加"Bearer "前缀

Examples

示例

Correct

正确示例


feat(auth): add Steam OAuth provider

Implement Steam OpenID authentication flow.
Follows existing Google/Discord pattern.

Closes #456

fix(api): handle null response from legacy endpoint

The /v0/users endpoint can return null for deleted users.
Add null check and return 404 instead of 500.

Fixes #789

refactor(components): extract CardBase from entity cards

DRY refactor - all entity cards now extend CardBase.
No functional changes.

feat(auth): 添加Steam OAuth提供商

实现Steam OpenID认证流程,遵循现有Google/Discord的实现模式。

关闭 #456

fix(api): 处理旧版接口返回的null值

/v0/users接口在用户删除后会返回null,添加空值检查并返回404而非500。

修复 #789

refactor(components): 从实体卡片中提取CardBase组件

DRY重构 - 所有实体卡片现在继承自CardBase组件,无功能变更。

Incorrect

错误示例


Fixed bug # No type, vague
FEAT: Add feature # Wrong case
feat(auth): Added Steam OAuth # Past tense
feat: implement the new system... # Too long (>72 chars)

Fixed bug # 无类型,描述模糊
FEAT: Add feature # 大小写错误
feat(auth): Added Steam OAuth # 过去式
feat: implement the new system... # 首行过长(超过72字符)

Exceptions

例外情况

  • Merge commits may use default message
  • Revert commits may use git's default format
  • 合并提交可使用默认消息
  • 回滚提交可使用Git默认格式

Enforcement

执行机制

  • commitlint in pre-commit hook
  • CI check on PRs
  • PR review
  • pre-commit钩子中的commitlint
  • PR中的CI检查
  • PR评审

References

参考链接

examples.md

examples.md

markdown
undefined
markdown
undefined

Commit Message Examples

提交消息示例

Feature Commits

功能提交


feat(creatures): add CR filtering to creature list

Allow filtering creatures by Challenge Rating range.
Uses dual-handle slider component.

Related: #234

feat(search): implement fuzzy search with MiniSearch

Replace substring matching with indexed fuzzy search.
Results ranked by relevance score.

Performance: <16ms for 10k entries

Closes #567

feat(creatures): 为生物列表添加CR筛选功能

允许按挑战等级范围筛选生物,使用双滑块组件实现。

相关:#234

feat(search): 使用MiniSearch实现模糊搜索

将子字符串匹配替换为索引化模糊搜索,结果按相关性评分排序。

性能:10k条数据查询耗时<16ms

关闭 #567

Bug Fix Commits

Bug修复提交


fix(cards): prevent image flash on card hover

Card images were reloading on every hover due to
missing key prop in map. Add stable key based on
entity slug.

Fixes #890

fix(auth): handle expired refresh tokens gracefully

When refresh token expires, redirect to login instead
of showing error page. Clear local storage on redirect.

Fixes #891
Fixes #892

fix(cards): 解决卡片 hover 时的图片闪烁问题

由于map中缺少key属性,卡片图片在每次hover时都会重新加载。添加基于实体slug的稳定key。

修复 #890

fix(auth): 优雅处理过期的刷新令牌

当刷新令牌过期时,重定向到登录页而非显示错误页面,重定向时清除本地存储。

修复 #891
修复 #892

Refactor Commits

重构提交


refactor(services): extract API client from services

Move HTTP logic to dedicated ApiClient class.
Services now use dependency injection.

No functional changes. Improves testability.

refactor(services): 从服务中提取API客户端

将HTTP逻辑迁移至独立的ApiClient类,服务现在使用依赖注入。

无功能变更,提升可测试性。

Documentation Commits

文档提交


docs(readme): add Docker setup instructions

Document docker-compose workflow for new developers.
Include troubleshooting section for common issues.

docs(readme): 添加Docker部署说明

为新开发者编写docker-compose工作流文档,包含常见问题排查章节。

Breaking Change Commits

破坏性变更提交


feat(api)!: rename /monsters to /creatures

BREAKING CHANGE: All /api/monsters/_ endpoints now at /api/creatures/_

Migration:

- Update all fetch calls
- /monsters/:slug -> /creatures/:slug

Deprecation notice sent 2026-01-01.
Old endpoints removed 2026-02-01.

feat(api)!: 将/monsters重命名为/creatures

BREAKING CHANGE: 所有/api/monsters/_端点现在迁移至/api/creatures/_

迁移说明:

- 更新所有请求调用
- /monsters/:slug -> /creatures/:slug

已于2026-01-01发送弃用通知,旧端点将于2026-02-01移除。

Chore Commits

维护提交


chore(deps): update dependencies

- react 18.2 -> 19.0
- vite 5.0 -> 7.3
- typescript 5.3 -> 5.8

No breaking changes.

chore(deps): 更新依赖包

- react 18.2 -> 19.0
- vite 5.0 -> 7.3
- typescript 5.3 -> 5.8

无破坏性变更。

CI Commits

CI提交


ci(github): add automated release workflow

Trigger on version tags, build and publish to npm.
Uses semantic-release for changelog generation.
undefined

ci(github): 添加自动发布工作流

在版本标签触发时,构建并发布至npm,使用semantic-release生成变更日志。
undefined

.enforced_by

.enforced_by

commitlint
husky pre-commit hook
GitHub Actions CI
PR review checklist

commitlint
husky pre-commit hook
GitHub Actions CI
PR评审检查清单

Example: docs/rules/git/branches/

示例:docs/rules/git/branches/

Branch naming conventions.
分支命名规范。

rule.md

rule.md

markdown
undefined
markdown
undefined

Rule: Branch Naming Conventions

规则:分支命名规范

Summary

概述

All branches MUST follow the pattern
{type}/{ticket}-{description}
.
所有分支必须遵循
{type}/{ticket}-{description}
格式。

Rationale

设计理由

Consistent branch naming:
  • Links work to tickets/issues
  • Indicates purpose at a glance
  • Enables automation (CI triggers, auto-linking)
  • Simplifies cleanup
一致的分支命名:
  • 将工作与工单/问题关联
  • 一眼即可看出分支用途
  • 支持自动化(CI触发、自动关联)
  • 简化分支清理

The Rule

规则详情

Format

格式


{type}/{ticket}-{short-description}

{type}/{ticket}-{简短描述}

Types

类型

TypeUse For
feature
New features
fix
Bug fixes
hotfix
Urgent production fixes
refactor
Code refactoring
docs
Documentation
test
Test additions
chore
Maintenance
release
Release preparation
类型用途
feature
新功能
fix
Bug修复
hotfix
紧急生产环境修复
refactor
代码重构
docs
文档更新
test
测试用例添加
chore
维护任务
release
发布准备

Requirements

要求

  1. MUST use lowercase
  2. MUST include ticket number (or
    no-ticket
    if none)
  3. MUST use hyphens for word separation
  4. SHOULD keep description under 30 characters
  5. MUST NOT include special characters except hyphen
  1. 必须使用小写
  2. 必须包含工单编号(若无则使用
    no-ticket
  3. 必须使用连字符分隔单词
  4. 建议描述长度不超过30个字符
  5. 禁止使用连字符以外的特殊字符

Protected Branches

受保护分支

  • main
    - Production code
  • develop
    - Integration branch (if used)
MUST NOT push directly to protected branches.
  • main
    - 生产环境代码
  • develop
    - 集成分支(若使用)
禁止直接推送到受保护分支。

Examples

示例

Correct

正确示例


feature/ORC-123-steam-oauth
fix/ORC-456-null-response-crash
hotfix/ORC-789-login-broken
refactor/ORC-101-extract-card-base
docs/no-ticket-api-readme
chore/ORC-202-update-deps
release/v1.2.0

feature/ORC-123-steam-oauth
fix/ORC-456-null-response-crash
hotfix/ORC-789-login-broken
refactor/ORC-101-extract-card-base
docs/no-ticket-api-readme
chore/ORC-202-update-deps
release/v1.2.0

Incorrect

错误示例


steam-oauth # No type, no ticket
feature/steam_oauth # Underscores
Feature/ORC-123-Steam-OAuth # Uppercase
feature/ORC-123-implement-the-new-steam-oauth-provider # Too long
feature/steam oauth # Spaces

steam-oauth # 无类型,无工单编号
feature/steam_oauth # 使用下划线
Feature/ORC-123-Steam-OAuth # 大写
feature/ORC-123-implement-the-new-steam-oauth-provider # 描述过长
feature/steam oauth # 包含空格

Exceptions

例外情况

  • main
    ,
    develop
    are allowed as-is
  • Dependabot branches follow their own format
  • main
    develop
    分支可保留原名
  • Dependabot分支遵循其自身格式

Enforcement

执行机制

  • Branch protection rules
  • CI validation
  • PR checks

---
  • 分支保护规则
  • CI验证
  • PR检查

---

Example: docs/rules/git/pull_requests/

示例:docs/rules/git/pull_requests/

PR requirements and templates.
PR要求与模板。

rule.md

rule.md

markdown
undefined
markdown
undefined

Rule: Pull Request Requirements

规则:拉取请求(PR)要求

Summary

概述

All PRs MUST include a description, link to ticket, and pass CI checks.
所有PR必须包含描述、关联工单并通过所有CI检查。

Rationale

设计理由

Well-documented PRs:
  • Enable effective code review
  • Provide context for future readers
  • Link work to requirements
  • Ensure quality before merge
文档完善的PR:
  • 支持高效的代码评审
  • 为后续维护者提供上下文
  • 将工作与需求关联
  • 确保合并前的代码质量

The Rules

规则详情

Required Elements

必填元素

  1. MUST have descriptive title (not branch name)
  2. MUST include summary of changes
  3. MUST link to ticket/issue
  4. MUST pass all CI checks
  5. MUST have at least one approval (for non-trivial changes)
  6. SHOULD include testing notes
  7. SHOULD include screenshots for UI changes
  1. 必须包含描述性标题(而非分支名称)
  2. 必须包含变更摘要
  3. 必须关联工单/问题
  4. 必须通过所有CI检查
  5. 必须至少获得一次批准(非 trivial 变更)
  6. 建议包含测试说明
  7. 建议为UI变更提供截图

Title Format

标题格式


[TYPE] Brief description (#ticket)
Examples:
  • [Feature] Add Steam OAuth (#ORC-123)
  • [Fix] Handle null API response (#ORC-456)
  • [Refactor] Extract CardBase component (#ORC-101)

[类型] 简短描述 (#工单编号)
示例:
  • [Feature] 添加Steam OAuth (#ORC-123)
  • [Fix] 处理API返回的null值 (#ORC-456)
  • [Refactor] 提取CardBase组件 (#ORC-101)

Size Guidelines

大小指南

  • SHOULD be under 400 lines changed
  • Large PRs SHOULD be split into smaller PRs
  • If >400 lines, add explanation of why
  • 建议变更代码行数不超过400行
  • 大型PR建议拆分为多个小型PR
  • 若超过400行,需说明原因

Review Requirements

评审要求

Change TypeRequired Approvals
Documentation only0 (self-merge OK)
Small fix (<50 lines)1
Feature/Refactor1
Breaking change2
Security-related2
变更类型所需批准数
仅文档更新0(可自合并)
小型修复(<50行)1
功能/重构1
破坏性变更2
安全相关变更2

Exceptions

例外情况

  • Automated dependency updates may auto-merge if CI passes
  • Documentation-only changes may self-merge
  • 自动依赖更新在CI通过后可自动合并
  • 仅文档变更可自合并

Enforcement

执行机制

  • GitHub branch protection rules
  • Required status checks
  • PR template
undefined
  • GitHub分支保护规则
  • 必填状态检查
  • PR模板
undefined

template.md

template.md

markdown
undefined
markdown
undefined

Summary

摘要

Brief description of what this PR does.
简述本PR的功能。

Related Issue

关联问题

Fixes #(issue number)
修复 #(问题编号)

Type of Change

变更类型

  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update
  • Refactoring (no functional changes)
  • Chore (dependencies, build, CI)
  • Bug修复(非破坏性变更)
  • 新功能(非破坏性变更)
  • 破坏性变更(会导致现有功能变化的修复或功能)
  • 文档更新
  • 代码重构(无功能变化)
  • 维护任务(依赖、构建、CI)

Changes Made

变更内容

  • Change 1
  • Change 2
  • Change 3
  • 变更1
  • 变更2
  • 变更3

Testing

测试说明

Describe how you tested these changes:
  • Unit tests added/updated
  • Manual testing performed
  • E2E tests added/updated
描述你如何测试这些变更:
  • 添加/更新单元测试
  • 执行手动测试
  • 添加/更新E2E测试

Screenshots (if applicable)

截图(如适用)

BeforeAfter
imgimg
变更前变更后
图片图片

Checklist

检查清单

  • My code follows the project's coding standards
  • I have performed a self-review of my code
  • I have commented my code where needed
  • I have updated the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix/feature works
  • New and existing tests pass locally
  • Any dependent changes have been merged

---
  • 代码符合项目编码规范
  • 已完成自我代码评审
  • 在需要的地方添加了代码注释
  • 已更新文档
  • 变更未产生新的警告
  • 添加了验证修复/功能的测试用例
  • 本地运行所有新旧测试均通过
  • 所有依赖的变更已合并

---

Example: docs/rules/git/reviews/

示例:docs/rules/git/reviews/

Code review standards.
代码评审标准。

rule.md

rule.md

markdown
undefined
markdown
undefined

Rule: Code Review Standards

规则:代码评审标准

Summary

概述

All code reviews MUST be constructive, timely, and thorough.
所有代码评审必须具有建设性、及时性且全面。

Rationale

设计理由

Effective code review:
  • Catches bugs before production
  • Shares knowledge across team
  • Maintains code quality
  • Improves developer skills
高效的代码评审:
  • 在生产环境前发现Bug
  • 团队内共享知识
  • 维持代码质量
  • 提升开发者技能

The Rules

规则详情

Reviewer Responsibilities

评审者职责

  1. MUST respond within 24 hours (business days)
  2. MUST provide actionable feedback
  3. MUST approve or request changes (no silent stalls)
  4. SHOULD suggest alternatives when blocking
  5. MUST distinguish blocking vs. non-blocking comments
  1. 必须在24小时内回复(工作日)
  2. 必须提供可执行的反馈
  3. 必须明确批准或要求变更(不得无响应)
  4. 建议在阻塞变更时提供替代方案
  5. 必须区分阻塞性与非阻塞性评论

Comment Conventions

评论规范

Use prefixes to clarify intent:
PrefixMeaningBlocking?
blocker:
Must fix before mergeYes
question:
Need clarificationMaybe
suggestion:
Consider this alternativeNo
nit:
Minor style preferenceNo
praise:
Positive feedbackNo
使用前缀明确意图:
前缀含义是否阻塞?
blocker:
合并前必须修复
question:
需要澄清可能
suggestion:
建议考虑此替代方案
nit:
轻微风格偏好
praise:
正面反馈

What to Review

评审要点

  1. Correctness: Does it do what it claims?
  2. Design: Is the approach appropriate?
  3. Readability: Is it understandable?
  4. Tests: Are changes tested?
  5. Documentation: Are comments/docs updated?
  6. Security: Any security concerns?
  7. Performance: Any performance issues?
  1. 正确性:是否实现了预期功能?
  2. 设计:实现方案是否合适?
  3. 可读性:代码是否易于理解?
  4. 测试:变更是否有测试覆盖?
  5. 文档:注释/文档是否已更新?
  6. 安全性:是否存在安全隐患?
  7. 性能:是否存在性能问题?

Author Responsibilities

提交者职责

  1. MUST respond to all comments
  2. MUST resolve or discuss blockers
  3. SHOULD implement non-blocking suggestions or explain why not
  4. MUST NOT merge with unresolved blockers
  1. 必须回复所有评论
  2. 必须解决或讨论阻塞性问题
  3. 建议采纳非阻塞性建议或说明不采纳的原因
  4. 禁止在阻塞性问题未解决时合并

Examples

示例

Good Review Comments

优秀的评审评论


blocker: This query is vulnerable to SQL injection.
Use parameterized queries instead:
`db.query('SELECT * FROM users WHERE id = ?', [userId])`

question: Why is this timeout set to 30 seconds?
Seems long for a user-facing request.

suggestion: Consider extracting this into a helper function.
It's used in three places.

nit: Prefer `const` over `let` here since it's never reassigned.

praise: Nice use of discriminated unions here!
Makes the error handling very clean.

blocker: 此查询存在SQL注入风险,请使用参数化查询:
`db.query('SELECT * FROM users WHERE id = ?', [userId])`

question: 为什么超时设置为30秒?对于用户请求来说似乎过长。

suggestion: 考虑将此提取为辅助函数,它在三个地方被使用。

nit: 此处建议使用`const`而非`let`,因为它从未被重新赋值。

praise: 这里很好地使用了判别式联合,错误处理非常清晰!

Poor Review Comments

糟糕的评审评论


This is wrong. # No explanation
I wouldn't do it this way. # No alternative
??? # Meaningless
LGTM # (for complex PR without real review)

This is wrong. # 无解释
I wouldn't do it this way. # 无替代方案
??? # 无意义
LGTM # 针对复杂PR未进行实际评审

Enforcement

执行机制

  • Review time tracked in GitHub insights
  • Stale PR alerts
  • Review checklist in PR template
undefined
  • GitHub Insights跟踪评审时间
  • 陈旧PR提醒
  • PR模板中的评审检查清单
undefined

checklist.md

checklist.md

markdown
undefined
markdown
undefined

Code Review Checklist

代码评审检查清单

Use this checklist when reviewing PRs:
评审PR时使用以下清单:

Basics

基础检查

  • PR description explains the changes
  • Related issue is linked
  • CI checks pass
  • PR描述清晰说明变更内容
  • 已关联相关问题
  • CI检查全部通过

Code Quality

代码质量

  • Code follows project coding standards
  • No unnecessary complexity
  • No code duplication
  • Functions/methods have single responsibility
  • Names are clear and descriptive
  • 代码符合项目编码规范
  • 无不必要的复杂度
  • 无代码重复
  • 函数/方法职责单一
  • 命名清晰且具有描述性

Correctness

正确性

  • Logic is correct
  • Edge cases are handled
  • Error handling is appropriate
  • No obvious bugs
  • 逻辑正确
  • 已处理边缘情况
  • 错误处理恰当
  • 无明显Bug

Testing

测试

  • New code has tests
  • Tests cover edge cases
  • Existing tests still pass
  • Test names describe what they test
  • 新代码有测试覆盖
  • 测试覆盖了边缘情况
  • 现有测试仍能通过
  • 测试名称准确描述测试内容

Security

安全性

  • No secrets in code
  • Input is validated
  • No SQL injection risks
  • No XSS vulnerabilities
  • Auth/authz is correct
  • 代码中无敏感信息
  • 输入已验证
  • 无SQL注入风险
  • 无XSS漏洞
  • 认证/授权逻辑正确

Performance

性能

  • No N+1 queries
  • No unnecessary re-renders
  • Large data sets paginated
  • Expensive operations optimized or async
  • 无N+1查询
  • 无不必要的重渲染
  • 大数据集已分页
  • 耗时操作已优化或异步处理

Documentation

文档

  • Code comments where needed
  • API docs updated
  • README updated if needed
  • 必要处添加了代码注释
  • API文档已更新
  • 必要时更新了README

Final

最终检查

  • I would be comfortable maintaining this code
  • Changes match what the PR description claims

---
  • 我愿意维护此代码
  • 变更与PR描述一致

---

Example: docs/rules/git/merging/

示例:docs/rules/git/merging/

Merge strategy rules.
合并策略规则。

rule.md

rule.md

markdown
undefined
markdown
undefined

Rule: Merge Strategy

规则:合并策略

Summary

概述

All merges to main MUST use squash merge with a descriptive commit message.
所有合并到main分支的操作必须使用 squash merge 并添加描述性提交消息。

Rationale

设计理由

Squash merging:
  • Keeps main history clean
  • Each commit represents one complete feature/fix
  • Simplifies git bisect
  • Enables clean reverts
Squash合并:
  • 保持main分支历史记录整洁
  • 每个提交代表一个完整的功能/修复
  • 简化git bisect操作
  • 支持干净的回滚

The Rules

规则详情

Default: Squash Merge

默认方式:Squash Merge

  1. MUST use squash merge for feature branches
  2. MUST write descriptive squash commit message
  3. SHOULD include PR number in commit message
  4. MUST delete branch after merge
  1. 必须对功能分支使用squash merge
  2. 必须编写描述性的squash提交消息
  3. 建议在提交消息中包含PR编号
  4. 必须在合并后删除分支

Exceptions: Regular Merge

例外情况:常规合并

Use regular merge only for:
  • Release branches to main (preserve history)
  • Long-running branches with meaningful commits
仅在以下场景使用常规合并:
  • 发布分支合并到main(保留历史记录)
  • 长期运行且提交有意义的分支

Commit Message for Squash

Squash提交消息

Follow same format as regular commits:

feat(auth): add Steam OAuth provider (#123)

Implement Steam OpenID authentication flow including:

- Steam provider configuration
- Callback handler
- Session management

Closes #456
遵循与常规提交相同的格式:

feat(auth): 添加Steam OAuth提供商 (#123)

实现Steam OpenID认证流程,包括:

- Steam提供商配置
- 回调处理
- 会话管理

关闭 #456

Branch Cleanup

分支清理

MUST delete merged branches:
  • GitHub: Enable "Automatically delete head branches"
  • Local:
    git fetch --prune
    regularly
必须删除已合并的分支:
  • GitHub:启用"自动删除源分支"
  • 本地:定期执行
    git fetch --prune

Enforcement

执行机制

  • GitHub branch protection: Require squash merge
  • Automatic branch deletion enabled
  • CI reminder for stale branches

---
  • GitHub分支保护:要求使用squash merge
  • 启用自动分支删除
  • CI提醒陈旧分支

---

Example: docs/rules/git/tags/

示例:docs/rules/git/tags/

Release tagging rules.
发布标签规则。

rule.md

rule.md

markdown
undefined
markdown
undefined

Rule: Release Tags

规则:发布标签

Summary

概述

All releases MUST be tagged with semantic version following
v{major}.{minor}.{patch}
.
所有发布必须使用语义化版本标签,格式为
v{major}.{minor}.{patch}

Rationale

设计理由

Semantic versioning:
  • Communicates impact of changes
  • Enables automated releases
  • Provides clear upgrade path
  • Links releases to code state
语义化版本:
  • 传达变更的影响范围
  • 支持自动发布
  • 提供清晰的升级路径
  • 将发布与代码状态关联

The Rules

规则详情

Version Format

版本格式


v{MAJOR}.{MINOR}.{PATCH}
  • MAJOR: Breaking changes
  • MINOR: New features, backward compatible
  • PATCH: Bug fixes, backward compatible

v{主版本}.{次版本}.{修订版本}
  • 主版本:破坏性变更
  • 次版本:新增功能,向后兼容
  • 修订版本:Bug修复,向后兼容

Pre-release Tags

预发布标签


v1.2.0-alpha.1
v1.2.0-beta.1
v1.2.0-rc.1

v1.2.0-alpha.1
v1.2.0-beta.1
v1.2.0-rc.1

Tagging Process

打标签流程

  1. MUST tag from main branch
  2. MUST update version in package.json first
  3. MUST use annotated tags (not lightweight)
  4. MUST include release notes in tag message
bash
undefined
  1. 必须从main分支打标签
  2. 必须先更新package.json中的版本号
  3. 必须使用带注释的标签(而非轻量标签)
  4. 必须在标签消息中包含发布说明
bash
undefined

Correct

正确方式

git tag -a v1.2.0 -m "Release v1.2.0: Feature X, Fix Y"
git tag -a v1.2.0 -m "发布v1.2.0:新增功能X,修复Bug Y"

Incorrect

错误方式

git tag v1.2.0 # Lightweight tag, no message
undefined
git tag v1.2.0 # 轻量标签,无消息
undefined

Release Notes

发布说明

MUST include:
  • Summary of changes
  • Breaking changes (if any)
  • Migration notes (if needed)
  • Contributors
必须包含:
  • 变更摘要
  • 破坏性变更(若有)
  • 迁移说明(若需要)
  • 贡献者

Examples

示例

Correct Tags

正确标签

v1.0.0          # First stable release
v1.1.0          # New feature
v1.1.1          # Bug fix
v2.0.0          # Breaking change
v2.0.0-beta.1   # Pre-release
v1.0.0          # 首个稳定版本
v1.1.0          # 新增功能
v1.1.1          # Bug修复
v2.0.0          # 破坏性变更
v2.0.0-beta.1   # 预发布版本

Incorrect Tags

错误标签

1.0.0           # Missing 'v' prefix
v1.0            # Missing patch version
release-1.0.0   # Wrong format
v1.0.0.0        # Too many parts
1.0.0           # 缺少'v'前缀
v1.0            # 缺少修订版本
release-1.0.0   # 格式错误
v1.0.0.0        # 版本段过多

Enforcement

执行机制

  • CI validates tag format
  • Release workflow triggered by tags
  • Changelog generated from commits

---
  • CI验证标签格式
  • 标签触发发布工作流
  • 从提交记录生成变更日志

---

Creating New Git Rules

创建新的Git规则

mermaid
flowchart TD
    A[Identify Need] --> B{Category}

    B -->|Commit| C[commits/]
    B -->|Branch| D[branches/]
    B -->|PR| E[pull_requests/]
    B -->|Review| F[reviews/]
    B -->|Merge| G[merging/]
    B -->|Release| H[tags/]

    C --> I[Create Folder]
    D --> I
    E --> I
    F --> I
    G --> I
    H --> I

    I --> J[Write rule.md]
    J --> K[Add examples.md]
    K --> L{Has Template?}

    L -->|Yes| M[Add template.md]
    L -->|No| N[Configure Enforcement]
    M --> N

    N --> O{Enforcement Type}
    O -->|Hook| P[Add to husky]
    O -->|CI| Q[Add GH Action]
    O -->|GitHub| R[Configure Settings]

    P --> S[Document in .enforced_by]
    Q --> S
    R --> S

    S --> T[Announce to Team]

mermaid
flowchart TD
    A[识别需求] --> B{分类}

    B -->|提交| C[commits/]
    B -->|分支| D[branches/]
    B -->|PR| E[pull_requests/]
    B -->|评审| F[reviews/]
    B -->|合并| G[merging/]
    B -->|发布| H[tags/]

    C --> I[创建目录]
    D --> I
    E --> I
    F --> I
    G --> I
    H --> I

    I --> J[编写rule.md]
    J --> K[添加examples.md]
    K --> L{是否有模板?}

    L -->|是| M[添加template.md]
    L -->|否| N[配置执行机制]
    M --> N

    N --> O{执行类型}
    O -->|钩子| P[添加到husky]
    O -->|CI| Q[添加GitHub Action]
    O -->|GitHub| R[配置设置]

    P --> S[在.enforced_by中记录]
    Q --> S
    R --> S

    S --> T[通知团队]

Signal Files Reference

信号文件参考

SignalTypeContentPurpose
.version
ContentJSON schema versionTrack rule version
.enforced_by
ContentList of toolsDocument enforcement
.deprecated
Empty-Mark as deprecated
.template
ContentTemplate file pathLink to templates

信号文件类型内容用途
.version
内容文件JSON schema版本跟踪规则版本
.enforced_by
内容文件工具列表记录执行机制
.deprecated
空文件-标记为已废弃
.template
内容文件模板文件路径关联模板文件

Rule Quality Checklist

规则质量检查清单

Before finalizing a git rule:
  • Rule is clear and unambiguous
  • Format patterns are documented
  • At least 3 correct examples
  • At least 3 incorrect examples
  • Exceptions are documented
  • Enforcement mechanism configured
  • GitHub settings updated if needed
  • Pre-commit hooks updated if needed
  • CI workflow added if needed
  • Team notified of new rule
最终确定Git规则前需检查:
  • 规则清晰且无歧义
  • 已记录格式模式
  • 至少包含3个正确示例
  • 至少包含3个错误示例
  • 已记录例外情况
  • 已配置执行机制
  • 已更新GitHub设置(若需要)
  • 已更新pre-commit钩子(若需要)
  • 已添加CI工作流(若需要)
  • 已通知团队新规则