git-workflow
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseGit 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>| Type | When to use |
|---|---|
| New feature or contract |
| Bug fix |
| Code restructure without behavior change |
| Add or update tests |
| Documentation changes |
| Build config, dependency updates, toolchain |
| Security fix or hardening |
使用Conventional Commits格式:
<type>: <short description>| Type | 适用场景 |
|---|---|
| 新功能或合约 |
| 漏洞修复 |
| 不改变原有行为的代码重构 |
| 新增或更新测试 |
| 文档变更 |
| 构建配置、依赖更新、工具链调整 |
| 安全修复或加固 |
Commit Workflow
提交流程
- Run to review all changes before staging
git diff - Stage specific files — avoid to prevent committing
git add .or artifacts.env - Write concise commit message describing the why, not the what
- Never add lines — commit messages should only contain the description
Co-Authored-By - Only commit — never unless explicitly requested
git push - Never push directly to main/master — always use feature branches
- 暂存文件前运行检查所有变更
git diff - 暂存指定文件 —— 避免使用防止误提交
git add .或构建产物.env - 编写简洁的提交信息,描述修改原因,而非修改内容
- 禁止添加行 —— 提交信息仅应包含变更描述
Co-Authored-By - 仅执行提交操作 —— 除非收到明确要求,否则不要执行
git push - 永远不要直接推送到main/master分支 —— 始终使用功能分支开发
Branch Naming
分支命名
| Pattern | Example |
|---|---|
| |
| |
| |
| 命名规则 | 示例 |
|---|---|
| |
| |
| |
PR Requirements
PR要求
Every PR must include:
| Section | Content |
|---|---|
| Change description | What was changed and why |
| Test results | |
| Gas impact | |
| Deployment impact | Does this affect deployed contracts? Migration needed? |
| Review focus | Specific areas that need careful review |
每个PR必须包含以下内容:
| 模块 | 内容 |
|---|---|
| 变更描述 | 修改的内容以及修改原因 |
| 测试结果 | |
| Gas影响 | 针对修改函数的 |
| 部署影响 | 是否影响已部署合约?是否需要执行迁移? |
| 审查重点 | 需要重点仔细审查的特定区域 |
Code Review Rules
代码审查规则
| Scenario | Requirement |
|---|---|
| Standard changes | Minimum 1 maintainer approval |
| Security-related changes | Minimum 2 maintainer approvals |
| AI-generated code | Must pass manual review + |
| Contract upgrades | Requires full team review + upgrade simulation on fork |
| 场景 | 要求 |
|---|---|
| 常规变更 | 至少1名维护者审批通过 |
| 安全相关变更 | 至少2名维护者审批通过 |
| AI生成代码 | 合并前必须通过人工审查 + |
| 合约升级 | 需要全团队审查 + 分叉环境下的升级模拟验证 |
AI Assistance Rules
AI辅助开发规则
- AI-generated code must pass before committing
forge test - 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 after AI generates code to ensure consistent formatting
forge fmt
- AI生成的代码提交前必须通过测试
forge test - 始终检查AI输出的以下内容:导入路径是否正确、访问控制是否合理、Gas消耗影响
- 在AI提示词中提供相关文件路径和测试用例,以获得更准确的输出结果
- AI生成代码后运行保证代码格式统一
forge fmt