git-workflow-and-versioning

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

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

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, clean history, 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 so multiple agents or streams of work run in isolation. - 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 work into clean atomic commits, open a reviewable PR, and tag a properly versioned release with a changelog entry. ## Quick Start Use the git workflow skill to split 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 uncommitted changes into atomic commits?▼

Split uncommitted work by staging one logical change at a time and committing each with a descriptive conventional message. Keep formatting changes separate from behavior changes, and target roughly 100 lines per commit so each stays reviewable and revertible.

What is trunk-based development and when should I use it?▼

Trunk-based development keeps main always deployable while work happens on short-lived feature branches merged within 1-3 days. It is the recommended default because long-lived branches accumulate merge risk; feature flags are preferred over long branches for incomplete work.

How do I use git worktrees for parallel work?▼

Use git worktree add to create separate directories, each checked out to its own branch, so multiple agents or features progress simultaneously without branch switching. When finished, merge the branch and remove the worktree with git worktree remove.

How do I choose a semantic version bump for a release?▼

Choose MAJOR for breaking changes, MINOR for backward-compatible functionality, and PATCH for backward-compatible fixes. When unsure whether a change is breaking, assume it is, since consumers may rely on observable behavior beyond the documented API.

What should I check before every git commit?▼

Before committing, review the staged diff, scan for secrets like passwords or API keys, run tests, linting, and type checking. Automate these checks with git hooks using tools like lint-staged and husky.

Why is a changelog different from git log output?▼

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, so entries should be written with the change, not reconstructed at release time.