Git Workflow with Conventions

VerifiedSafe

Enforces branch naming conventions (feature/fix/hotfix), commit message formatting (Conventional Commits style), secret file detection to prevent accidental commits, and safety guards that block pushes to protected branches. Helps maintain consistent project history and security when using Git on collaborative repositories.

Sby Skills Guide Bot
DevelopmentIntermediate
506/2/2026
Claude Code
#git#workflow#branching#commit-conventions#secret-protection

Recommended for

Our review

This skill enforces strict conventions for branches, commit messages, and secret protection within a Git repository.

Strengths

  • Automates adherence to branch naming and commit formatting conventions
  • Prevents secret leaks by blocking sensitive files from being committed
  • Blocks pushes to protected branches and enforces pull requests
  • Manages .gitignore creation and maintenance

Limitations

  • Requires following predefined conventions, which may be restrictive
  • Does not handle advanced conflict resolution or complex Git workflows
  • Secret detection relies on a static pattern list, not content analysis
When to use it

Use this skill to standardize Git operations in a team project and avoid common mistakes like secret leaks.

When not to use it

Avoid this skill for projects requiring flexible conventions or highly customized Git workflows.

Security analysis

Safe
Quality score90/100

The skill only uses git commands (via bash) to enforce branching, commit formatting, and secret protection. No destructive or exfiltrating operations are instructed. It includes safety guards to block pushes to protected branches and prevent committing secret files.

No concerns found

Examples

Create a feature branch
Create a new branch for the user login feature.
Commit with proper format
Commit my staged changes with a message describing the fix for the payment bug.
Push while protecting secrets
Push my commits, but first check for any accidentally staged secret files.

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:

  1. Add pattern to .gitignore
  2. Unstage file: git reset HEAD [file]
  3. 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:

  1. Branch name matches convention?
  2. Commit message format correct?
  3. No secrets in staged files?
  4. 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?"
Related skills