git-workflow-and-versioning

Structures git commits, branching, worktrees, and semantic versioning for code changes.

Updated Apr 28, 2026
One-click install
npx skills add https://github.com/visdomtech/skills --skill git-workflow-and-versioning-visdomtech
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: git-workflow-and-versioning
Source: https://github.com/visdomtech/skills/tree/main/git-workflow-and-versioning
Command: npx skills add https://github.com/visdomtech/skills --skill git-workflow-and-versioning-visdomtech

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code changes made without version control discipline become impossible to review, revert, or debug. This Skill enforces atomic commits, short-lived branches, and consistent release versioning so every change stays manageable and traceable. ## Core Features & Use Cases - Commit Discipline: Enforces atomic commits with conventional message types (feat, fix, refactor, test, docs, chore) and pre-commit hygiene checks for secrets, tests, and linting. - Branching & Parallel Work: Guides trunk-based development with short-lived feature branches and git worktrees for running multiple parallel work streams. - Release & Versioning: Applies semantic versioning (MAJOR.MINOR.PATCH), annotated git tags as the source of truth, and human-readable changelogs grouped by impact. - Use Case: An AI agent finishes a messy working session with mixed changes. Use this Skill to split the uncommitted work into clean atomic commits, write descriptive messages, and open a reviewable pull request. ## Quick Start Use the git-workflow-and-versioning skill to organize my uncommitted changes into atomic commits and prepare a pull request.

Frequently Asked Questions about git-workflow-and-versioning

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I split a large uncommitted change into atomic commits?▼

Split large changes by staging one logical slice at a time and committing each with a descriptive message. Target roughly 100 lines per commit, keep refactoring separate from feature work, and never mix formatting changes with behavior changes.

What commit message format should I use for git?▼

Use the format "type: short description" with types like feat, fix, refactor, test, docs, and chore. The body should explain why the change was made, not what the diff already shows.

How do git worktrees help with parallel development?▼

Git worktrees let you check out multiple branches in separate directories simultaneously, so agents or developers can work in parallel without branch switching. Each worktree is isolated until explicitly merged, and failed experiments can be removed cleanly.

When should I bump major, minor, or patch in semantic versioning?▼

Bump MAJOR for breaking changes, MINOR for backward-compatible new functionality, and PATCH for backward-compatible bug fixes. When unsure whether a change is breaking, assume it is, since a surprise major is cheaper than a broken consumer.

Why is a changelog different from git log?▼

A changelog is a curated, consumer-facing summary grouped by Added, Changed, Fixed, Deprecated, Removed, and Security, phrased around user impact. Raw commit logs bury what matters and are written for developers, not consumers.

What files should never be committed to git?▼

Never commit build output like dist/ or .next/, environment files like .env, or dependency folders like node_modules/. Set up a .gitignore immediately covering node_modules/, dist/, .env, .env.local, and *.pem to prevent leaking secrets.