# Process Guide ## Basic Principles ### 1. Include Plenty of Concrete Examples Present concrete code examples, not just abstract rules. **Bad example**: ``` Make variable names easy to understand ``` **Good example**: ```typescript // ✅ Good: The role is clear const userAuthentication = new UserAuthenticationService(); const taskRepository = new TaskRepository(); // ❌ Bad: Ambiguous const auth = new Service(); const repo = new Repository(); ``` ### 2. Explain the Reasoning Make clear "why we do it this way." **Example**: ``` ## Don't Ignore Errors Reason: Ignoring errors makes it difficult to identify the cause of a problem. Handle expected errors appropriately, and propagate unexpected errors upward so they can be recorded in the logs. ``` ### 3. Set Measurable Criteria Avoid vague expressions and provide concrete numbers. **Bad example**: ``` Keep code coverage high ``` **Good example**: ``` Code coverage targets: - Unit tests: 80% or higher - Integration tests: 60% or higher - E2E tests: 100% of the main flows ``` ## Git Operation Rules ### Branching Strategy (Adopting Git Flow) **What is Git Flow**: A branching model proposed by Vincent Driessen that systematically manages feature development, releases, and hotfixes. With clearly divided roles, it enables parallel work and stable releases in team development. **Branch structure**: ``` main (production environment) └── develop (development/integration environment) ├── feature/* (new feature development) ├── fix/* (bug fixes) └── release/* (release preparation) *as needed ``` **Operation rules**: - **main**: Holds only stable code already released to production. Versioned with tags - **develop**: Integrates the latest development code for the next release. Automated tests run in CI - **feature/\*, fix/\***: Branch from develop, and merge into develop via a PR after the work is complete - **No direct commits**: Require PR review on all branches to ensure code quality - **Merge policy**: Recommend squash merge for feature→develop, and a merge commit for develop→main **Benefits of Git Flow**: - Branch roles are clear, making parallel development by multiple people easier - The production environment (main) is always kept clean - During emergencies, hotfix branches enable rapid response (introduce as needed) ### Commit Message Conventions **Conventional Commits is recommended**: ``` ():