How do I install the Git Workflow And Versioning skill?

Run npx skillmds@latest add vignesh2027/git-workflow-and-versioning in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Git Workflow And Versioning skill do?

Branching strategy, commit discipline, PR hygiene, and semantic versioning It is listed under Productivity on SkillMD.

Is Git Workflow And Versioning safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Git Workflow And Versioning?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Git Workflow And Versioning free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Git Workflow And Versioning?

vignesh2027 (@vignesh2027) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Git Workflow And Versioning by vignesh2027

Name: Git Workflow And Versioning
Author: vignesh2027

File contents

Overview

Git history is documentation. A clear commit history enables fast debugging, safe reverts, and meaningful changelogs. This skill enforces the habits that make git useful as a tool rather than just a backup system.

When to Use

Before starting any branch
Before committing changes
Before creating a PR
When tagging a release

Process

Step 1: Branch naming

Use: <type>/<description> — e.g., feat/user-search, fix/login-redirect, chore/update-deps Types: feat, fix, docs, chore, refactor, perf, test

Step 2: Commit messages

Follow Conventional Commits:

<type>(<scope>): <description>

[optional body]
[optional footer]

Examples:

feat(auth): add OAuth2 login with Google
fix(api): handle null user_id in /profile endpoint
perf(db): add index on users.email column

Rules:

Description is imperative mood ("add" not "added")
Under 72 characters
One logical change per commit
Reference ticket: Closes #123

Step 3: Keep PRs small

A PR should be reviewable in under 30 minutes. If it takes longer, it's too big. Split it.

One logical change per PR
No PRs with 500+ line diffs (with rare exceptions)
No WIP code in a PR

Step 4: PR description

Every PR must have:

What changed (not a list of files, but a description of the change)
Why it changed
How to test it
Screenshots for UI changes
Link to the ticket

Step 5: Semantic versioning

MAJOR.MINOR.PATCH

MAJOR: breaking change (removing an API, changing a contract)
MINOR: backward-compatible new feature
PATCH: backward-compatible bug fix

Tag releases: git tag v1.2.3 -m "Release 1.2.3"

Step 6: Git hygiene

Never force push to main/master
Never commit secrets (use pre-commit hooks: gitleaks, detect-secrets)
Rebase feature branches on main before merging (or squash)
Delete branches after merge

Verification Requirements

Branch follows naming convention
Commits follow Conventional Commits format
PR has description with: what, why, how to test
PR is reviewable in under 30 minutes
No secrets committed (pre-commit hook confirms)
Release tagged with semantic version

---name: git-workflow-and-versioningdescription: Branching strategy, commit discipline, PR hygiene, and semantic versioning---## OverviewGit history is documentation. A clear commit history enables fast debugging, safe reverts, and meaningful changelogs. This skill enforces the habits that make git useful as a tool rather than just a backup system.## When to Use- Before starting any branch- Before committing changes- Before creating a PR- When tagging a release## Process### Step 1: Branch namingUse: `<type>/<description>` — e.g., `feat/user-search`, `fix/login-redirect`, `chore/update-deps`Types: `feat`, `fix`, `docs`, `chore`, `refactor`, `perf`, `test`### Step 2: Commit messagesFollow Conventional Commits:```<type>(<scope>): <description>[optional body][optional footer]```Examples:- `feat(auth): add OAuth2 login with Google`- `fix(api): handle null user_id in /profile endpoint`- `perf(db): add index on users.email column`Rules:- Description is imperative mood ("add" not "added")- Under 72 characters- One logical change per commit- Reference ticket: `Closes #123`### Step 3: Keep PRs smallA PR should be reviewable in under 30 minutes. If it takes longer, it's too big. Split it.- One logical change per PR- No PRs with 500+ line diffs (with rare exceptions)- No WIP code in a PR### Step 4: PR descriptionEvery PR must have:- What changed (not a list of files, but a description of the change)- Why it changed- How to test it- Screenshots for UI changes- Link to the ticket### Step 5: Semantic versioning`MAJOR.MINOR.PATCH`- MAJOR: breaking change (removing an API, changing a contract)- MINOR: backward-compatible new feature- PATCH: backward-compatible bug fixTag releases: `git tag v1.2.3 -m "Release 1.2.3"`### Step 6: Git hygiene- Never force push to main/master- Never commit secrets (use pre-commit hooks: `gitleaks`, `detect-secrets`)- Rebase feature branches on main before merging (or squash)- Delete branches after merge## Verification Requirements- [ ] Branch follows naming convention- [ ] Commits follow Conventional Commits format- [ ] PR has description with: what, why, how to test- [ ] PR is reviewable in under 30 minutes- [ ] No secrets committed (pre-commit hook confirms)- [ ] Release tagged with semantic version

Frequently asked questions

Git Workflow And Versioning