git-workflow

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Git Collaboration Standards

Git 协作规范

Language Rule

语言规则

  • Always respond in the same language the user is using. If the user asks in Chinese, respond in Chinese. If in English, respond in English.
  • 始终使用与用户相同的语言回复。如果用户用中文提问,就用中文回复;如果用英文提问,就用英文回复。

Commit Rules

提交规则

Use Conventional Commits format:
<type>: <short description>
TypeWhen to use
feat:
New feature or contract
fix:
Bug fix
refactor:
Code restructure without behavior change
test:
Add or update tests
docs:
Documentation changes
chore:
Build config, dependency updates, toolchain
security:
Security fix or hardening
使用Conventional Commits格式:
<type>: <short description>
Type适用场景
feat:
新功能或合约
fix:
漏洞修复
refactor:
不改变原有行为的代码重构
test:
新增或更新测试
docs:
文档变更
chore:
构建配置、依赖更新、工具链调整
security:
安全修复或加固

Commit Workflow

提交流程

  1. Run
    git diff
    to review all changes before staging
  2. Stage specific files — avoid
    git add .
    to prevent committing
    .env
    or artifacts
  3. Write concise commit message describing the why, not the what
  4. Never add
    Co-Authored-By
    lines
    — commit messages should only contain the description
  5. Only commit — never
    git push
    unless explicitly requested
  6. Never push directly to main/master — always use feature branches
  1. 暂存文件前运行
    git diff
    检查所有变更
  2. 暂存指定文件 —— 避免使用
    git add .
    防止误提交
    .env
    或构建产物
  3. 编写简洁的提交信息,描述修改原因,而非修改内容
  4. 禁止添加
    Co-Authored-By
    —— 提交信息仅应包含变更描述
  5. 仅执行提交操作 —— 除非收到明确要求,否则不要执行
    git push
  6. 永远不要直接推送到main/master分支 —— 始终使用功能分支开发

Branch Naming

分支命名

PatternExample
feat/<name>
feat/staking-pool
fix/<name>
fix/reentrancy-guard
refactor/<name>
refactor/token-structure
命名规则示例
feat/<name>
feat/staking-pool
fix/<name>
fix/reentrancy-guard
refactor/<name>
refactor/token-structure

PR Requirements

PR要求

Every PR must include:
SectionContent
Change descriptionWhat was changed and why
Test results
forge test
output (all pass)
Gas impact
forge test --gas-report
diff for changed functions
Deployment impactDoes this affect deployed contracts? Migration needed?
Review focusSpecific areas that need careful review
每个PR必须包含以下内容:
模块内容
变更描述修改的内容以及修改原因
测试结果
forge test
输出(所有用例通过)
Gas影响针对修改函数的
forge test --gas-report
差异对比
部署影响是否影响已部署合约?是否需要执行迁移?
审查重点需要重点仔细审查的特定区域

Code Review Rules

代码审查规则

ScenarioRequirement
Standard changesMinimum 1 maintainer approval
Security-related changesMinimum 2 maintainer approvals
AI-generated codeMust pass manual review +
forge test
before merge
Contract upgradesRequires full team review + upgrade simulation on fork
场景要求
常规变更至少1名维护者审批通过
安全相关变更至少2名维护者审批通过
AI生成代码合并前必须通过人工审查 +
forge test
测试
合约升级需要全团队审查 + 分叉环境下的升级模拟验证

AI Assistance Rules

AI辅助开发规则

  • AI-generated code must pass
    forge test
    before committing
  • Always review AI output for: correct import paths, proper access control, gas implications
  • Include relevant file paths and test cases in AI prompts for better results
  • Run
    forge fmt
    after AI generates code to ensure consistent formatting
  • AI生成的代码提交前必须通过
    forge test
    测试
  • 始终检查AI输出的以下内容:导入路径是否正确、访问控制是否合理、Gas消耗影响
  • 在AI提示词中提供相关文件路径和测试用例,以获得更准确的输出结果
  • AI生成代码后运行
    forge fmt
    保证代码格式统一