Skip to content
Back to skills

Git Workflows

ASecurity

Git and GitHub workflow patterns, commit conventions, branching strategies, and PR best practices. Use when making commits, creating branches, opening PRs, or resolving conflicts.

  • 6 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 8, 2026
ai-agentsgogitci/cd

Security analysis

A100/100

Scanned September 8, 2026

npx -y skills add kmshihab7878/claude-code-setup --skill git-workflows --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Git Workflows?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Git Workflows
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/kmshihab7878-git-workflows/badge)](https://www.skillsdirectory.com/skills/kmshihab7878-git-workflows)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: git-workflows
description: >
  Git and GitHub workflow patterns, commit conventions, branching strategies, and PR best practices.
  Use when making commits, creating branches, opening PRs, or resolving conflicts.
---

# git-workflows

Git and GitHub workflow patterns.

## how to use

- `/git-workflows`
  Apply these conventions to all git operations in this conversation.

- `/git-workflows <context>`
  Review the context against rules below and suggest improvements.

## when to apply

Reference these guidelines when:
- writing commit messages
- creating or naming branches
- opening or reviewing pull requests
- resolving merge conflicts
- deciding between rebase and merge
- running destructive git commands

## rule categories by priority

| priority | category | impact |
|----------|----------|--------|
| 1 | commit conventions | critical |
| 2 | branching strategy | critical |
| 3 | PR best practices | high |
| 4 | conflict resolution | high |
| 5 | destructive commands | critical |
| 6 | repository hygiene | medium |

## quick reference

### 1. commit conventions (critical)

- follow Conventional Commits: `type(scope): description`
- valid types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`
- scope is optional but encouraged for multi-module repos
- description must be imperative mood, lowercase, no period
- body explains WHY, not WHAT (the diff shows what)
- breaking changes: add `!` after type/scope and `BREAKING CHANGE:` in footer
- keep subject line under 72 characters
- one logical change per commit; split unrelated changes

### 2. branching strategy (critical)

- main/master: always deployable, protected
- feature branches: `feature/<ticket>-<short-description>`
- bug fixes: `fix/<ticket>-<short-description>`
- hotfixes: `hotfix/<description>` (branch from main, merge to main + develop)
- release branches: `release/<version>` when applicable
- delete branches after merge
- never commit directly to main/master

**Decision tree**:
- Single developer, simple project: trunk-based with short-lived branches
- Team with CI/CD: GitHub Flow (main + feature branches)
- Multiple release versions: Git Flow (main + develop + feature/release/hotfix)

### 3. PR best practices (high)

- title: concise, under 70 chars, describes the change
- description: include Summary (what + why), Test Plan, and Breaking Changes
- keep PRs focused: one concern per PR
- prefer small PRs (< 400 lines changed)
- link related issues with `Closes #123` or `Fixes #123`
- request reviewers explicitly
- address all review comments before merging
- use draft PRs for work-in-progress

### 4. conflict resolution (high)

- pull/rebase frequently to minimize conflicts
- understand both sides before resolving; never blindly accept one side
- test after resolving conflicts
- for complex conflicts, discuss with the other author
- prefer `git rebase` for local-only branches to maintain linear history
- prefer `git merge` for shared branches to preserve context

### 5. destructive commands (critical)

- **never** force-push to main/master or shared branches
- **always** confirm before: `git reset --hard`, `git clean -f`, `git checkout .`, `git push --force`
- prefer `--force-with-lease` over `--force` when force-pushing
- back up work before destructive operations: `git stash` or create a backup branch
- `git reflog` is your safety net for recovering lost commits
- never use `--no-verify` to skip hooks without explicit user request

### 6. repository hygiene (medium)

- keep `.gitignore` up to date; never commit generated files, build artifacts, or secrets
- use `.gitattributes` for line ending consistency
- tag releases with semantic versioning: `v1.2.3`
- write meaningful branch descriptions for long-lived branches
- prune stale remote branches periodically: `git remote prune origin`
- keep commit history clean; squash fixup commits before merge

## common fixes

| problem | fix |
|---------|-----|
| wrong commit message | `git commit --amend` (if not pushed) |
| committed to wrong branch | `git stash`, switch branch, `git stash pop` |
| need to undo last commit | `git reset --soft HEAD~1` (keeps changes staged) |
| accidentally committed secrets | remove file, add to .gitignore, use `git filter-repo` to purge history, rotate credentials immediately |
| merge conflict in lockfile | delete lockfile, regenerate, commit |
| diverged from remote | `git pull --rebase` for linear history |

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…