Memorize the git workflow
This commit is contained in:
@@ -16,3 +16,51 @@ Use `@/openspec/AGENTS.md` to learn:
|
||||
Keep this managed block so 'openspec update' can refresh the instructions.
|
||||
|
||||
<!-- OPENSPEC:END -->
|
||||
|
||||
# Git Workflow
|
||||
|
||||
## Branching Strategy
|
||||
|
||||
**IMPORTANT:** This project uses feature branch workflow for all changes.
|
||||
|
||||
### All Future Changes
|
||||
When the user requests a new feature, change, or proposal:
|
||||
|
||||
1. **Create a feature branch** before starting any work:
|
||||
```bash
|
||||
git checkout -b feature/descriptive-name
|
||||
```
|
||||
|
||||
2. **Work on the feature branch** during:
|
||||
- OpenSpec proposal creation
|
||||
- Design and planning
|
||||
- Implementation
|
||||
- Testing
|
||||
|
||||
3. **Commit regularly** with conventional commit messages:
|
||||
- `feat:` for new features
|
||||
- `fix:` for bug fixes
|
||||
- `docs:` for documentation
|
||||
- `refactor:` for code refactoring
|
||||
- `test:` for tests
|
||||
|
||||
4. **Only merge to main** after user approval:
|
||||
- User reviews the changes
|
||||
- User explicitly approves
|
||||
- Then merge or create PR
|
||||
|
||||
### Branch Naming Convention
|
||||
- Features: `feature/short-description`
|
||||
- Fixes: `fix/issue-description`
|
||||
- Docs: `docs/what-changed`
|
||||
- Examples:
|
||||
- `feature/add-blog-section`
|
||||
- `feature/cv-page`
|
||||
- `fix/mobile-navigation`
|
||||
- `docs/update-readme`
|
||||
|
||||
### Main Branch Protection
|
||||
- `main` branch represents stable, reviewed code
|
||||
- Never commit directly to `main` (except initial setup)
|
||||
- All changes go through feature branches
|
||||
- Keeps history clean and reviewable
|
||||
Reference in New Issue
Block a user