Git workflow guide

Skill The-AI-Directory-Company/agents-and-skills/skills/git-workflow-guide

70+ AI agent templates and 55+ skill definitions for Claude Code, Cursor, Windsurf, and other AI coding tools. Community-maintained, MIT licensed. Follows the Agent Skills specification.

Install

npx -y skills add The-AI-Directory-Company/agents-and-skills --skill git-workflow-guide

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Git workflow reference covering branch naming, commit message conventions, PR templates, merge strategies, and common operations — for consistent team collaboration.

SKILL.md

4.9 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

Git Workflow Guide

Before you start

Confirm the following for the project:

What is the branching model? — Trunk-based, GitFlow, or GitHub Flow
What is the main branch name? — main or master
Are there branch protection rules? — Required reviews, CI checks, linear history
What is the merge strategy? — Squash, rebase, or merge commit
Is there a commit message convention? — Conventional Commits, Angular, or custom

If these are not documented, ask the team lead before establishing your own pattern. Inconsistency in git workflows creates merge conflicts and confusion.

Branch naming

Use this format:

<type>/<ticket-id>-<short-description>

Types:

feat/ — New feature
fix/ — Bug fix
refactor/ — Code restructuring without behavior change
docs/ — Documentation only
test/ — Adding or updating tests
chore/ — Build, CI, dependency updates

Examples:

feat/PROJ-123-add-user-search
fix/PROJ-456-null-check-login
refactor/PROJ-789-extract-auth-module
chore/update-eslint-config

Rules:

Lowercase only
Hyphens between words, not underscores
Include ticket ID when one exists
Keep the description under 5 words
Delete branches after merging

Commit messages

Format

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

<body>

<footer>

Type (required)

feat, fix, refactor, docs, test, chore, perf, ci, style

Scope (optional)

The module, component, or area affected: auth, api, ui, db, ci

Subject (required)

Imperative mood: "add" not "added" or "adds"
Lowercase first letter
No period at the end
Max 72 characters

Examples

feat(auth): add password reset flow         ← feature with scope
fix(api): handle null user ID in session    ← bug fix with scope
chore: update TypeScript to 5.4             ← chore, no scope needed
refactor(db): extract query builder module  ← refactor with scope

Add a body for non-trivial changes explaining WHY, not HOW. Reference tickets in the footer: Closes #234.

Pull request template

Use this structure for PR descriptions:

## What
[1-2 sentences: what this PR does]

## Why
[Why this change is needed — link to ticket]

## Testing
- [ ] Unit tests added/updated
- [ ] Manual testing performed

## Notes for reviewers
[Anything the reviewer should pay attention to]

Merge strategies

Strategy	When to use	Command
Squash merge	Messy branch history, want clean main	`git merge --squash branch` then commit
Rebase merge	Each commit is meaningful and clean	`git rebase main` then `git merge --ff-only`
Merge commit	Long-lived branches, need diverge/converge history	`git merge --no-ff branch`

Squash is the safest default for feature branches. Use rebase when commits are well-structured. Use merge commits for release branches.

Key operations

# Sync branch with main (use --force-with-lease, never --force)
git checkout main && git pull && git checkout feat/my-branch && git rebase main

# Undo last commit, keep changes
git reset --soft HEAD~1

# Stash work in progress
git stash push -m "description"

Quality checklist

Before opening a PR, verify:

Branch name follows the naming convention
Commits are meaningful — no WIP, fixup, or "oops" messages left
PR description follows the template with What/Why/Testing/Notes
Branch is rebased on the latest main (no unnecessary merge commits)
CI passes on the branch
The diff contains only changes related to the stated purpose

Common mistakes

Committing to main directly. Always work on a branch, even for small changes. Direct commits bypass review and CI.
Writing vague commit messages. "Fix bug" and "Update code" tell reviewers nothing. State what changed and why.
Using force push on shared branches. Force push overwrites remote history. Use --force-with-lease and never force push to main.
Letting branches go stale. Rebase on main regularly. A branch that diverges for weeks will have painful merge conflicts.
Including unrelated changes in a PR. One PR should do one thing. Refactoring plus a bug fix plus a new feature in one PR is unreviewable.
Not deleting merged branches. Stale branches clutter the repository. Delete branches after they are merged.

Gives 2 of the 12 instructions most pr commit review skills give in ~1.1k tokens

Counted across 888 of the 1,342 authors here whose files we hold, read 2026-08-06

use conventional commits formatin 123 of 888, across 110 files
keep subject line under 72 charactersin 60 of 888, across 46 files
delete branches after mergehere, and in 50 of 888, across 37 files
use imperative mood in subject linein 50 of 888, across 41 files
use imperative mood in commit messageshere, and in 45 of 888
generate a conventional commit messagein 42 of 888
make atomic commitsin 37 of 888, across 25 files
run tests before committingin 36 of 888, across 24 files
run project test suite to verify clean baselinein 35 of 888, across 7 files
run detected project setup commandsin 34 of 888, across 6 files
wrap commit body at 72 charactersin 32 of 888, across 25 files
split unrelated changes into separate commitsin 32 of 888, across 27 files

Said here and by no other author read

ask the team lead if workflow is undocumented
keep branch descriptions under five words
verify CI passes before opening a pull request
ensure diffs contain only related changes

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.