How do I install the Git Workflow And Versioning skill?

Run npx skillmds@latest add tomevault-io/git-workflow-and-versioning-6 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.

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?

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

Git Workflow And Versioning by tomevault-io

Name: Git Workflow And Versioning
Author: tomevault-io

File contents

Git Workflow and Versioning

Core Model: Trunk-Based Development

Keep main always deployable. Use short-lived feature branches (1–3 days).

"Every day a branch lives, it accumulates merge risk."

Five Core Practices

Commit frequently — treat commits as save points after each successful increment
Atomic commits — each commit handles one logical task
Descriptive messages — explain the why using conventional format:
- feat:, fix:, refactor:, test:, docs:, chore:
Separate concerns — don't mix formatting with behavior; don't mix refactoring with features
Right-size changes — aim for ~~100 lines per commit; split anything >~~1000 lines

Branch Naming

feature/task-creation
fix/duplicate-tasks
chore/update-deps

Before Committing

Tests pass
No secrets accidentally staged
Linting clean
Staged changes match intent (no accidental includes)

What Not to Commit

Build output
.env files
IDE configs
node_modules/, dist/, __pycache__/

The Save Point Pattern

If tests fail after a commit, revert that one increment of work. Don't accumulate broken commits.

Conda-Forge Application

Apply when preparing recipe commits and PRs:

Atomic: one commit per recipe (or per meaningful fix)
Message format: feat: add <package-name> recipe / fix: <package-name>: resolve missing stdlib dep
Right-sized: a PR adding one recipe should touch only that recipe's directory
Change summary: document what you intentionally didn't modify to prevent scope creep
Never force-push to main after a PR is open

Source: rxm7706/local-recipes — distributed by TomeVault.

---name: git-workflow-and-versioning-6description: Disciplined version control. Trunk-based development, atomic commits, descriptive messages, right-sized changes. Use when this capability is needed.---# Git Workflow and Versioning## Core Model: Trunk-Based DevelopmentKeep `main` always deployable. Use short-lived feature branches (1–3 days).> "Every day a branch lives, it accumulates merge risk."## Five Core Practices1. **Commit frequently** — treat commits as save points after each successful increment2. **Atomic commits** — each commit handles one logical task3. **Descriptive messages** — explain the *why* using conventional format: - `feat:`, `fix:`, `refactor:`, `test:`, `docs:`, `chore:`4. **Separate concerns** — don't mix formatting with behavior; don't mix refactoring with features5. **Right-size changes** — aim for ~100 lines per commit; split anything >~1000 lines## Branch Naming```feature/task-creationfix/duplicate-taskschore/update-deps```## Before Committing- [ ] Tests pass- [ ] No secrets accidentally staged- [ ] Linting clean- [ ] Staged changes match intent (no accidental includes)## What Not to Commit- Build output- `.env` files- IDE configs- `node_modules/`, `dist/`, `__pycache__/`## The Save Point PatternIf tests fail after a commit, revert that one increment of work. Don't accumulate broken commits.## Conda-Forge ApplicationApply when preparing recipe commits and PRs:- **Atomic**: one commit per recipe (or per meaningful fix)- **Message format**: `feat: add <package-name> recipe` / `fix: <package-name>: resolve missing stdlib dep`- **Right-sized**: a PR adding one recipe should touch only that recipe's directory- **Change summary**: document what you *intentionally didn't modify* to prevent scope creep- **Never force-push** to `main` after a PR is open---> Source: [rxm7706/local-recipes](https://github.com/rxm7706/local-recipes) — distributed by [TomeVault](https://tomevault.io).

Frequently asked questions

Git Workflow And Versioning