skills.rest
lugassawan
lugassawanCOMMUNITY
Explore all skills by this author →
GitHub

principle-version-control

Guide Git version control with atomic commits and clear PR descriptions.

2|8|Updated Apr 20, 2026
Search Tags:#git#pull requests#branching strategy#commit hygiene#squash merge#rebase vs merge
One-click install
npx skills add https://github.com/lugassawan/swe-workbench --skill principle-version-control
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: principle-version-control
Source: https://github.com/lugassawan/swe-workbench/tree/main/skills/principle-version-control
Command: npx skills add https://github.com/lugassawan/swe-workbench --skill principle-version-control

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Prevents confusing, unreviewable commit history by enforcing atomic changes, high-signal commit messages, and disciplined branching/PR practices.

Core Features & Use Cases

  • Atomic commits for reliable bisect and safe reverts: split by concern (refactor vs behavior vs tests) so each commit has a single revert reason.
  • Commit-message quality for long-term maintainability: use an imperative subject and a body that explains why and what would break if reverted.
  • Branching and PR hygiene for low review friction: choose feature branches vs trunk-based development appropriately, apply rebase/merge/squash rules intentionally, and write PR descriptions that answer what/why/how-to-test.

Quick Start

Ask the assistant: "How should I split my current work into atomic commits, what commit-message format should I use, and should this PR be squash-merged or preserve history based on our review needs?"

Frequently Asked Questions about principle-version-control

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

FAQPage Schema
What's the best way to split large changes into atomic Git commits?▼

Git commit messages should use an imperative subject line and a body explaining why the change was made and what would break if reverted. This maintains long-term project maintainability and context.

How do I choose between squash merge and rebase vs merge for pull requests?▼

Feature branches suit isolated, long-lived features, while trunk-based development fits continuous integration with smaller, frequent commits. Choose your branching strategy to minimize review friction and maintain trustworthy Git history.

How do I write pull request descriptions that clearly state what changed and how to verify it?▼

Write pull request descriptions that answer what changed, why it matters, and how to test it via repro steps. This provides necessary context for reviewers and ensures changes are safely verifiable before merging.

Why do I need to isolate logic changes from formatting in Git commits?▼

Isolating logic changes from formatting in Git commits is needed to ensure reliable bisecting and safe reverts. Mixing formatting with behavior changes obscures the actual logic, making commit history unreviewable and debugging difficult.

Related Skills

Explore More Software Engineering Skills→
BillChiricoBillChirico
5

git-workspace-init

Create an isolated git worktree with conventional branch naming and upstream tracking.

Community
Intermediate
ka2kamaka2kama
2

review-and-merge

Automate pull request review, feedback handling, and merge execution.

Community
Advanced
Sir-chawakornSir-chawakorn
33

pr-review

Automate Pull Request reviews for code quality, security, and performance.

Community
Advanced
vndkubivndkubi

conventional-commit

Generate conventional commit messages from staged changes.

Community
Intermediate