Notre avis

Cette compétence applique des conventions strictes pour les branches, les messages de commit et la protection des secrets dans un dépôt Git.

Points forts

Automatise le respect des conventions de nommage
Bloque les commits contenant des fichiers sensibles
Empêche les pushs sur les branches protégées
Fournit un mode interactif pour guider l'utilisateur

Limites

Nécessite une configuration via le fichier conventions.md
Ne couvre pas tous les cas d'utilisation avancée (rebase, cherry-pick)
Les règles de validation peuvent être trop rigides pour certaines équipes

Quand l'utiliser

Quand vous travaillez dans un repo nécessitant des conventions de nommage strictes et une protection contre les fuites de secrets.

Quand l'éviter

Pour des projets personnels ou des équipes préférant une flexibilité totale sans règles imposées.

Exemples

Create a feature branch

Create a new branch for adding user authentication. Scope: auth. Description: login-page.

Commit with conventional message

Stage all changed files and commit with a message describing the fix for the login button scope ui.

Push without risk

Push my current branch to remote, but ensure I'm not pushing to a protected branch.

name: git description: Git workflow with enforced branch naming, commit formatting, secret protection, and safety guards. Use when: creating branches, committing changes, pushing code, merging, resolving conflicts, creating PRs. Triggers: git operations, create branch, commit, push, merge, branch naming, commit message format. allowed-tools: Bash(git:*)

Git Workflow

Enforces repository conventions for branches, commits, and pushes.

Conventions: See @.claude/skills/git/references/conventions.md

Process

VALIDATE → EXECUTE → VERIFY

Decision Rules

Branch Type

New functionality → feature/<scope>/<desc>
Bug fix → fix/<scope>/<desc>
Refactor → refactor/<scope>/<desc>
Docs → docs/<scope>/<desc>
Maintenance → chore/<scope>/<desc>
Urgent fix → hotfix/<desc>
Release → release/<version>

Commit Type

Feature → feature(<scope>): ...
Fix → fix(<scope>): ...
Refactor → refactor(<scope>): ...
Test → test(<scope>): ...
Docs → docs(<scope>): ...

Source Branch

feature/fix/refactor/docs/chore → from main
hotfix → from release/* or main
release → from main

Secret Protection

Protected Patterns

Files (block commit):

*.env
*.env.*
*.pem
*.key
*.p12
*.pfx
*.crt
credentials.*
secrets.*
*_secret.*
*.keystore

Directories (block commit):

.secrets/
.credentials/

Allowed exceptions:

*.env.example
*.example

Pre-Commit Check

Before any commit, scan staged files:

git diff --cached --name-only

If protected pattern detected:

⚠ Secret Protection

Detected secret file staged for commit:
  [filename]

Action: Adding to .gitignore and unstaging file.

Then:

Add pattern to .gitignore
Unstage file: git reset HEAD [file]
Continue commit without secret

.gitignore Management

If .gitignore doesn't exist:

ℹ Creating .gitignore

Project has no .gitignore. Creating with security patterns.

Create with standard security block:

# Secrets - NEVER COMMIT
.env
.env.*
!.env.example
*.pem
*.key
*.p12
*.secret
.secrets/
.credentials/

If .gitignore exists but missing pattern:

Append missing pattern to existing .gitignore.

Safety Guards

Block Operations

| Trigger | Action | |---------|--------| | Push to main/master/release/*/prod/* | Block → suggest PR | | Force-push on shared branch | Block | | Amend after push | Block → suggest new commit | | Secret file in staged changes | Block → update .gitignore | | Binary >100MB | Block |

Warn Only

Binary >10MB

Validation

Before commit/push:

Branch name matches convention?
Commit message format correct?
No secrets in staged files?
Not pushing to protected branch?

Interactive Mode

When ambiguous, ask:

"Possible actions:
1. Create branch
2. Commit changes  
3. Push commits
Which matches your intent?"

Workflow Git Sécurisé

Recommandé pour