git-workflow-and-versioning

Structures git commits, branching, and worktree workflows for disciplined version control.

5|Updated Mar 5, 2024
One-click install
npx skills add https://github.com/TRAPZZY/God-Eyes --skill git-workflow-and-versioning-trapzzy
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: git-workflow-and-versioning
Source: https://github.com/TRAPZZY/God-Eyes/tree/main/.skills/git-workflow-and-versioning
Command: npx skills add https://github.com/TRAPZZY/God-Eyes --skill git-workflow-and-versioning-trapzzy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? AI agents and developers generating code at high speed often produce giant unreviewable commits, vague messages, and diverging long-lived branches, making changes hard to review, debug, and revert. This Skill enforces disciplined version control so every change stays manageable and reversible. ## Core Features & Use Cases - Atomic Commit Discipline: Enforces small, single-purpose commits with conventional message types (feat, fix, refactor, test, docs, chore) that explain the why behind each change. - Trunk-Based Branching Strategy: Keeps main always deployable with short-lived feature branches, branch naming conventions, and git worktrees for parallel agent work. - Pre-Commit Hygiene & Debugging: Provides checklists for staged diff review, secret scanning, tests, linting, and git bisect/blame workflows for debugging. - Use Case: An AI coding agent completes a feature slice, runs tests, scans the staged diff for secrets, commits with a descriptive conventional message, and provides a structured change summary listing what was and was not touched. ## Quick Start Use the git workflow skill to commit my current changes as atomic commits with proper messages and a change summary.

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 write good git commit messages?▼

Use the format 'type: short description' with types like feat, fix, refactor, test, docs, or chore. Add an optional body explaining why the change was made, not what changed, since the diff already shows the what.

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

Trunk-based development keeps main always deployable with short-lived feature branches merged within 1-3 days. DORA research correlates it with high-performing teams, and it avoids the merge risk that long-lived branches accumulate.

How do I run multiple git branches in parallel with worktrees?▼

Use 'git worktree add ../project-feature-a feature/task-creation' to create a separate directory per branch. Each worktree has its own branch, so agents or developers can work in parallel without switching, then remove worktrees after merging.

How large should a git commit or pull request be?▼

Target around 100 lines per commit or PR for easy review and reverts. Changes near 300 lines are acceptable for a single logical change, but anything approaching 1000 lines should be split into smaller commits.

How do I find which commit introduced a bug?▼

Use git bisect: run 'git bisect start', mark HEAD as bad and a known-good commit as good, then test each midpoint checkout until git narrows down the offending commit. git blame and git log --grep also help trace changes.

What files should never be committed to git?▼

Never commit environment files like .env, build output like dist/ or .next/, node_modules/, or private keys like *.pem. Set up a .gitignore immediately and scan staged diffs for passwords, secrets, and tokens before committing.