Skip to main content

git-workflow-and-versioning

Branching strategy, commit discipline, PR hygiene, and semantic versioning

설치로 이동

소스 정보

저장소
vignesh2027/AI-AGENT-SKILLS
최근 소스 활동
2026년 5월 13일 19:03
감지된 SKILL.md 언어
영어
스타
1
포크
0

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
git-workflow-and-versioning
description
Branching strategy, commit discipline, PR hygiene, and semantic versioning
difficulty
junior
domains
["general"]
## Overview Git history is documentation. A clear commit history enables fast debugging, safe reverts, and meaningful changelogs. This skill enforces the habits that make git useful as a tool rather than just a backup system. ## When to Use - Before starting any branch - Before committing changes - Before creating a PR - When tagging a release ## Process ### Step 1: Branch naming Use: `<type>/<description>` — e.g., `feat/user-search`, `fix/login-redirect`, `chore/update-deps` Types: `feat`, `fix`, `docs`, `chore`, `refactor`, `perf`, `test` ### Step 2: Commit messages Follow Conventional Commits: ``` <type>(<scope>): <description> [optional body] [optional footer] ``` Examples: - `feat(auth): add OAuth2 login with Google` - `fix(api): handle null user_id in /profile endpoint` - `perf(db): add index on users.email column` Rules: - Description is imperative mood ("add" not "added") - Under 72 characters - One logical change per commit - Reference ticket: `Closes #123` ### Step 3: Keep PRs small A PR should be reviewable in under 30 minutes. If it takes longer, it's too big. Split it. - One logical change per PR - No PRs with 500+ line diffs (with rare exceptions) - No WIP code in a PR ### Step 4: PR description Every PR must have: - What changed (not a list of files, but a description of the change) - Why it changed - How to test it - Screenshots for UI changes - Link to the ticket ### Step 5: Semantic versioning `MAJOR.MINOR.PATCH` - MAJOR: breaking change (removing an API, changing a contract) - MINOR: backward-compatible new feature - PATCH: backward-compatible bug fix Tag releases: `git tag v1.2.3 -m "Release 1.2.3"` ### Step 6: Git hygiene - Never force push to main/master - Never commit secrets (use pre-commit hooks: `gitleaks`, `detect-secrets`) - Rebase feature branches on main before merging (or squash) - Delete branches after merge ## Verification Requirements - [ ] Branch follows naming convention - [ ] Commits follow Conventional Commits format - [ ] PR has description with: what, why, how to test - [ ] PR is reviewable in under 30 minutes - [ ] No secrets committed (pre-commit hook confirms) - [ ] Release tagged with semantic version
GitHub에서 보기