2025-10-27 10:32:07 +01:00
|
|
|
|
|
|
|
|
# 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
|
2025-10-27 10:57:47 +01:00
|
|
|
- Keeps history clean and reviewable
|
|
|
|
|
|
|
|
|
|
<!-- OPENSPEC:START -->
|
|
|
|
|
# OpenSpec Instructions
|
|
|
|
|
|
|
|
|
|
These instructions are for AI assistants working in this project.
|
|
|
|
|
|
|
|
|
|
Always open `@/openspec/AGENTS.md` when the request:
|
|
|
|
|
- Mentions planning or proposals (words like proposal, spec, change, plan)
|
|
|
|
|
- Introduces new capabilities, breaking changes, architecture shifts, or big performance/security work
|
|
|
|
|
- Sounds ambiguous and you need the authoritative spec before coding
|
|
|
|
|
|
|
|
|
|
Use `@/openspec/AGENTS.md` to learn:
|
|
|
|
|
- How to create and apply change proposals
|
|
|
|
|
- Spec format and conventions
|
|
|
|
|
- Project structure and guidelines
|
|
|
|
|
|
|
|
|
|
Keep this managed block so 'openspec update' can refresh the instructions.
|
|
|
|
|
|
|
|
|
|
<!-- OPENSPEC:END -->
|
