Secure Git Workflow

VerifiedSafe

Enforces strict repository conventions: branch naming, commit formatting, secret protection, and safety guards. Validates and secures all Git operations.

Sby Skills Guide Bot
DevelopmentIntermediate
206/2/2026
Claude Code
#git#workflow#branch-naming#commit-conventions#secret-protection

Recommended for

Our review

This skill enforces strict conventions for branch naming, commit messages, and secret protection in a Git repository.

Strengths

  • Automates adherence to naming conventions
  • Blocks commits containing sensitive files
  • Prevents pushes to protected branches
  • Provides an interactive mode to guide the user

Limitations

  • Requires configuration via the conventions.md file
  • Does not cover advanced use cases like rebase or cherry-pick
  • Validation rules may be too strict for some teams
When to use it

When working in a repo that demands strict naming conventions and protection against secret leaks.

When not to use it

For personal projects or teams that prefer full flexibility without imposed rules.

Security analysis

Safe
Quality score85/100

The skill guides Git operations with safety checks, secret scanning, and restrictions on dangerous pushes. It uses Bash only for standard git commands and does not exfiltrate or disable safety.

No concerns found

Examples

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:

  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