Cline rules

1# Version Control
2 
3Rules for git and version control practices.
4 
5## Git Best Practices
6 
7- **Git Commits**: Use git after every major change to the project. Commit frequently with clear, descriptive messages that explain what changed and why.
8 
9## Git Commit Message Best Practices
10 
11Follow these guidelines for effective commit messages:
12 
13### Core Principles
14- **50/72 Rule**: Keep subject line ≤50 characters, body lines ≤72 characters
15- **Imperative Mood**: Use "Add", "Fix", "Update" (not "Added", "Fixed", "Updated")
16- **Explain Why**: Focus on the problem solved, not just the implementation
17 
18### Conventional Commits Format
19```
20<type>[optional scope]: <description>
21 
22[optional body]
23 
24[optional footer]
25```
26 
27**Common Types**:
28- `feat`: New feature (MINOR version bump)
29- `fix`: Bug fix (PATCH version bump)  
30- `docs`: Documentation changes
31- `refactor`: Code restructuring without behavior change
32- `test`: Adding or updating tests
33- `chore`: Maintenance tasks, dependency updates
34- `style`: Code formatting, whitespace changes
35- `build`: Build system or external dependency changes
36- `ci`: Continuous integration configuration
37- `perf`: Performance improvements
38 
39### Examples
40**Good**:
41```
42feat(auth): add social login via Google and GitHub
43fix: prevent race condition in request handling
44docs: update README with deployment instructions
45```
46 
47**Bad**:
48```
49updates
50fixed bug
51try again
52```
53 
54### Breaking Changes
55Indicate with `!` after type/scope or `BREAKING CHANGE:` in footer:
56```
57feat(api)!: remove deprecated endpoint
58```
59 
60### Reference
61For comprehensive guidance, see: `docs/guidance/git-commit-message-best-practices.md`
62