Notre avis

Définit des normes pour l'utilisation de Git, notamment les messages de commit conventionnels, les stratégies de branche et la gestion des conflits.

Points forts

Encourage des commits atomiques avec des messages structurés (Conventional Commits)
Fournit des règles claires pour les flux de travail et les noms de branches
Inclut une checklist avant commit pour éviter les erreurs courantes

Limites

Impose une convention spécifique qui peut ne pas convenir à toutes les équipes
Ne couvre pas les opérations avancées comme le rebase ou le cherry-pick
Peut être trop rigide pour des projets personnels ou très petits

Quand l'utiliser

Utilisez cette compétence lorsque vous travaillez sur un projet partagé avec plusieurs contributeurs et que vous souhaitez maintenir un historique clair et traçable.

Quand l'éviter

Évitez si votre équipe suit déjà une autre convention de commits ou si le projet est solo et que l'historique n'a pas besoin d'être strict.

Exemples

Commit message for a feature

Write a commit message following conventional commits for implementing JWT token validation in the authentication module.

Branching strategy for a bug fix

Suggest a branching strategy and branch name for fixing an issue where search results are not handled gracefully when empty.

Pre-commit review

Check my current git status and staged files, and help me stage only relevant changes while ignoring node_modules and .env files before committing.

name: git description: Standards for version control, commit messages, and branching strategy allowed-tools: run_command version: 1.0 priority: CRITICAL

Git - Version Control Standards

CRITICAL SKILL - Maintain a clean, traversable, and semantic history.

Core Principles

| Principle | Rule | |-----------|------| | Atomic Commits | One logical change per commit (e.g., "Fix bug" vs "Fix bug and add feature") | | Conventional Commits | Use structured messages (feat, fix, docs, refactor, etc.) | | Clean History | Don't commit broken code. Squash WIP commits before merging. | | Ignore Artifacts | Never commit derived files (builds, local configs, secrets). |

Commit Message Convention

Follow the Conventional Commits specification:

<type>(<scope>): <subject>

<body>

<footer>

Types

| Type | Description | |------|-------------| | feat | A new feature | | fix | A bug fix | | docs | Documentation only changes | | style | Changes that do not affect the meaning of the code (white-space, formatting, etc) | | refactor | A code change that neither fixes a bug nor adds a feature | | perf | A code change that improves performance | | test | Adding missing tests or correcting existing tests | | chore | Changes to the build process or auxiliary tools and libraries |

Examples

Good:

feat(auth): implement jwt token validation
fix(search): handle empty result sets gracefully
docs(readme): update installation instructions

Bad:

update code
fix bug
wip

Workflow Rules

Before Committing:
- Check git status to see what will be staged.
- Run git diff to review changes line-by-line.
- Ensure sensitive data (API keys) is NOT included.
Branching (if applicable):
- main / master: Stable production code.
- develop / dev: Integration branch.
- feat/feature-name: Feature branches.
- fix/issue-description: Bug fix branches.
Handling Conflicts:
- Pull changes from remote often to minimize conflicts.
- Resolve conflicts manually, understanding both sides of the change.

Common Commands Checklist

| Action | Command | |--------|---------| | Check Status | git status | | View Changes | git diff | | Stage Files | git add <file> (Avoid git add . unless sure) | | Commit | git commit -m "type(scope): message" | | Log | git log --oneline --graph --decorate --all |

🔴 Self-Check Before Committing

Ask yourself:

Does this commit break the build?
Did I accidentally include node_modules, venv, or .env?
Is the commit message descriptive enough for someone else to understand 6 months from now?

Git - Normes de contrôle de version

Recommandé pour