ogt-docs-rules-git
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseOGT 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.mddocs/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.mdExample: docs/rules/git/commits/
示例:docs/rules/git/commits/
Commit message format rules.
提交消息格式规则。
Folder Structure
目录结构
docs/rules/git/commits/
├── rule.md
├── examples.md
├── .version
└── .enforced_bydocs/rules/git/commits/
├── rule.md
├── examples.md
├── .version
└── .enforced_byrule.md
rule.md
markdown
undefinedmarkdown
undefinedRule: 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
类型
| Type | Use When |
|---|---|
| New feature |
| Bug fix |
| Documentation only |
| Formatting, no code change |
| Neither fixes nor adds feature |
| Performance improvement |
| Adding/updating tests |
| Maintenance tasks |
| CI/CD changes |
| Build system changes |
| 类型 | 使用场景 |
|---|---|
| 新功能 |
| Bug修复 |
| 仅文档更新 |
| 格式调整,无代码逻辑变更 |
| 既不是修复也不是新增功能的重构 |
| 性能优化 |
| 添加/更新测试 |
| 维护任务 |
| CI/CD流程变更 |
| 构建系统变更 |
Requirements
要求
- MUST use lowercase type
- MUST use imperative mood ("add" not "added")
- MUST limit first line to 72 characters
- SHOULD include scope for clarity
- MUST reference issue number for bug fixes
- MUST mark breaking changes with or footer
!
- 必须使用小写类型
- 必须使用祈使语气(如"add"而非"added")
- 必须限制首行长度不超过72个字符
- 建议包含作用域以提升清晰度
- 必须在Bug修复中引用问题编号
- 必须通过或页脚标记破坏性变更
!
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
参考链接
undefinedundefinedexamples.md
examples.md
markdown
undefinedmarkdown
undefinedCommit 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 checklistcommitlint
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
undefinedmarkdown
undefinedRule: 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
类型
| Type | Use For |
|---|---|
| New features |
| Bug fixes |
| Urgent production fixes |
| Code refactoring |
| Documentation |
| Test additions |
| Maintenance |
| Release preparation |
| 类型 | 用途 |
|---|---|
| 新功能 |
| Bug修复 |
| 紧急生产环境修复 |
| 代码重构 |
| 文档更新 |
| 测试用例添加 |
| 维护任务 |
| 发布准备 |
Requirements
要求
- MUST use lowercase
- MUST include ticket number (or if none)
no-ticket - MUST use hyphens for word separation
- SHOULD keep description under 30 characters
- MUST NOT include special characters except hyphen
- 必须使用小写
- 必须包含工单编号(若无则使用)
no-ticket - 必须使用连字符分隔单词
- 建议描述长度不超过30个字符
- 禁止使用连字符以外的特殊字符
Protected Branches
受保护分支
- - Production code
main - - Integration branch (if used)
develop
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
例外情况
- ,
mainare allowed as-isdevelop - 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
undefinedmarkdown
undefinedRule: 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
必填元素
- MUST have descriptive title (not branch name)
- MUST include summary of changes
- MUST link to ticket/issue
- MUST pass all CI checks
- MUST have at least one approval (for non-trivial changes)
- SHOULD include testing notes
- SHOULD include screenshots for UI changes
- 必须包含描述性标题(而非分支名称)
- 必须包含变更摘要
- 必须关联工单/问题
- 必须通过所有CI检查
- 必须至少获得一次批准(非 trivial 变更)
- 建议包含测试说明
- 建议为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 Type | Required Approvals |
|---|---|
| Documentation only | 0 (self-merge OK) |
| Small fix (<50 lines) | 1 |
| Feature/Refactor | 1 |
| Breaking change | 2 |
| Security-related | 2 |
| 变更类型 | 所需批准数 |
|---|---|
| 仅文档更新 | 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模板
undefinedtemplate.md
template.md
markdown
undefinedmarkdown
undefinedSummary
摘要
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)
截图(如适用)
| Before | After |
|---|---|
| img | img |
| 变更前 | 变更后 |
|---|---|
| 图片 | 图片 |
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
undefinedmarkdown
undefinedRule: 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
评审者职责
- MUST respond within 24 hours (business days)
- MUST provide actionable feedback
- MUST approve or request changes (no silent stalls)
- SHOULD suggest alternatives when blocking
- MUST distinguish blocking vs. non-blocking comments
- 必须在24小时内回复(工作日)
- 必须提供可执行的反馈
- 必须明确批准或要求变更(不得无响应)
- 建议在阻塞变更时提供替代方案
- 必须区分阻塞性与非阻塞性评论
Comment Conventions
评论规范
Use prefixes to clarify intent:
| Prefix | Meaning | Blocking? |
|---|---|---|
| Must fix before merge | Yes |
| Need clarification | Maybe |
| Consider this alternative | No |
| Minor style preference | No |
| Positive feedback | No |
使用前缀明确意图:
| 前缀 | 含义 | 是否阻塞? |
|---|---|---|
| 合并前必须修复 | 是 |
| 需要澄清 | 可能 |
| 建议考虑此替代方案 | 否 |
| 轻微风格偏好 | 否 |
| 正面反馈 | 否 |
What to Review
评审要点
- Correctness: Does it do what it claims?
- Design: Is the approach appropriate?
- Readability: Is it understandable?
- Tests: Are changes tested?
- Documentation: Are comments/docs updated?
- Security: Any security concerns?
- Performance: Any performance issues?
- 正确性:是否实现了预期功能?
- 设计:实现方案是否合适?
- 可读性:代码是否易于理解?
- 测试:变更是否有测试覆盖?
- 文档:注释/文档是否已更新?
- 安全性:是否存在安全隐患?
- 性能:是否存在性能问题?
Author Responsibilities
提交者职责
- MUST respond to all comments
- MUST resolve or discuss blockers
- SHOULD implement non-blocking suggestions or explain why not
- MUST NOT merge with unresolved blockers
- 必须回复所有评论
- 必须解决或讨论阻塞性问题
- 建议采纳非阻塞性建议或说明不采纳的原因
- 禁止在阻塞性问题未解决时合并
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模板中的评审检查清单
undefinedchecklist.md
checklist.md
markdown
undefinedmarkdown
undefinedCode 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
undefinedmarkdown
undefinedRule: 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
- MUST use squash merge for feature branches
- MUST write descriptive squash commit message
- SHOULD include PR number in commit message
- MUST delete branch after merge
- 必须对功能分支使用squash merge
- 必须编写描述性的squash提交消息
- 建议在提交消息中包含PR编号
- 必须在合并后删除分支
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: regularly
git fetch --prune
必须删除已合并的分支:
- 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
undefinedmarkdown
undefinedRule: 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
打标签流程
- MUST tag from main branch
- MUST update version in package.json first
- MUST use annotated tags (not lightweight)
- MUST include release notes in tag message
bash
undefined- 必须从main分支打标签
- 必须先更新package.json中的版本号
- 必须使用带注释的标签(而非轻量标签)
- 必须在标签消息中包含发布说明
bash
undefinedCorrect
正确方式
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
undefinedgit tag v1.2.0 # 轻量标签,无消息
undefinedRelease 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-releasev1.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 parts1.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
信号文件参考
| Signal | Type | Content | Purpose |
|---|---|---|---|
| Content | JSON schema version | Track rule version |
| Content | List of tools | Document enforcement |
| Empty | - | Mark as deprecated |
| Content | Template file path | Link to templates |
| 信号文件 | 类型 | 内容 | 用途 |
|---|---|---|---|
| 内容文件 | JSON schema版本 | 跟踪规则版本 |
| 内容文件 | 工具列表 | 记录执行机制 |
| 空文件 | - | 标记为已废弃 |
| 内容文件 | 模板文件路径 | 关联模板文件 |
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工作流(若需要)
- 已通知团队新规则