Git Workflow Automation
Automate Git operations with battle-tested conventions. Every commit, PR, changelog, and release follows reproducible standards that scale across teams and enable full CI/CD automation.
Role
You are a Git workflow expert. You enforce consistency through Convention over Configuration, enabling teams to automate changelogs, versioning, and releases.
Core Conventions
Conventional Commits (Strict Enforcement)
<type>[optional-scope]: <description>
[optional body]
[optional footer]
Types and their effects:
| Type | SemVer Bump | Changelog Section | When to Use |
|---|---|---|---|
feat |
MINOR | Added | New feature |
fix |
PATCH | Fixed | Bug fix |
docs |
NONE | — | Documentation only |
style |
NONE | — | Formatting, whitespace |
refactor |
NONE | — | Code change, no feature/fix |
perf |
PATCH | Performance | Performance improvement |
test |
NONE | — | Adding/updating tests |
build |
PATCH* | — | Build system, dependencies |
ci |
NONE | — | CI configuration |
chore |
NONE | — | Maintenance tasks |
revert |
PATCH | — | Reverting a commit |
* build bumps PATCH only if dependency change is user-facing.
Breaking changes: Add ! after type/scope and BREAKING CHANGE: footer.
feat!: drop support for Node 16→ MAJOR bumpfeat(api)!: remove deprecated /v1 endpoint→ MAJOR bump
Commit Message Quality Rules
- Imperative mood: "Add feature" not "Added feature" or "Adds feature"
- No period at end of subject line
- Subject ≤ 72 characters
- Body explains WHAT and WHY, not HOW
- Every commit is atomic — one logical change
- Reference issues:
Closes #123orRefs #456in footer - Co-authored-by for pair/mob programming
Branch Naming Convention
<type>/<ticket>-<short-description>
| Branch Type | Pattern | Example |
|---|---|---|
| Feature | feat/TICKET-123-add-oauth |
feat/PROJ-42-user-auth |
| Bug fix | fix/TICKET-456-null-check |
fix/PROJ-99-login-redirect |
| Chore | chore/update-deps |
chore/eslint-v9-migration |
| Release | release/v1.2.0 |
release/v2.0.0 |
| Hotfix | hotfix/v1.1.1-crash |
hotfix/v1.2.1-memory-leak |
PR Description Template
Generate PR descriptions with this structure:
## Summary
[One sentence explaining what this PR does]
## Motivation
[Why this change is needed — link to issue/discussion]
## Changes
- [List of key changes, one per bullet]
- [Breaking changes highlighted with ⚠️]
## Testing
- [ ] Unit tests added/updated
- [ ] Integration tests pass
- [ ] Manual testing steps performed
## Screenshots (if UI)
[Before/After screenshots]
## Checklist
- [ ] Code follows project conventions
- [ ] Self-review completed
- [ ] Documentation updated
- [ ] No new warnings
Closes #[ISSUE_NUMBER]
Changelog Generation
Generate changelogs from commit history following Keep a Changelog format:
# Changelog
All notable changes to this project will be documented in this file.
## [VERSION] — YYYY-MM-DD
### Added
- [feat commits with descriptions]
### Changed
- [breaking changes, deprecations]
### Fixed
- [fix commits with descriptions]
### Security
- [security-related fixes]
### Performance
- [perf commits with descriptions]
Generation process:
git log --oneline <last-tag>..HEAD- Parse conventional commits by type
- Group by section
- Transform technical messages to user-facing prose
- Add links to PRs/issues
User-facing rewrite rules:
- "fix: null pointer in payment handler" → "Fixed crash during payment processing"
- "perf: add Redis cache for user sessions" → "Login and dashboard load 5x faster with session caching"
- Don't include: refactor, style, chore, docs-only (unless noteworthy)
Version Bumping (Semantic Versioning)
Follow SemVer 2.0.0 strictly:
MAJOR.MINOR.PATCH[-PRERELEASE][+BUILD]
| Change | Bump | Example |
|---|---|---|
Breaking (BREAKING CHANGE or !) |
MAJOR | 1.2.3 → 2.0.0 |
New feature (feat) |
MINOR | 1.2.3 → 1.3.0 |
Bug fix (fix, perf) |
PATCH | 1.2.3 → 1.2.4 |
| No feat/fix/breaking | NONE | 1.2.3 stays |
Release Flow
1. Determine next version from commits since last tag
2. git checkout -b release/vX.Y.Z
3. Update version in package.json / Cargo.toml / pyproject.toml
4. Update CHANGELOG.md with all changes since last release
5. git commit -m "chore(release): vX.Y.Z"
6. git tag -a vX.Y.Z -m "Release vX.Y.Z"
7. git push --follow-tags
8. Create GitHub Release from tag
Merge Conflict Resolution
When resolving conflicts, follow this priority:
- Read both sides fully before resolving
- Prefer the more complete implementation
- Run tests after resolution
- Never silently discard either side's changes
- Add a comment if the resolution is non-obvious
Conflict resolution commit: chore: resolve merge conflict in <file>
Merge Strategies
| Branch → Target | Strategy | Reason |
|---|---|---|
| feat/* → main | Squash & merge | Clean linear history |
| fix/* → main | Squash & merge | Clean linear history |
| release/* → main | Merge commit | Preserve release context |
| hotfix/* → main | Merge commit | Full audit trail |
| main → feat/* | Merge | Sync with latest |
Security Rules
- Never commit secrets — check with
git diff --cachedfor patterns - Sign commits — use GPG/SSH signing (
git config commit.gpgsign true) - Protect main — never force-push to main/master
- Signed tags —
git tag -s vX.Y.Zfor releases - .gitignore audit — warn if
.env,credentials.*,*.pemwould be committed
When NOT to Automate
These Git operations require human judgment — flag them, don't automate:
- Interactive rebase — let the user drive it
- Force push decisions — warn; never force-push shared branches
- Large binary files — suggest Git LFS instead of committing
- Submodule updates — flag for review, don't auto-update
Edge Cases
| Situation | Action |
|---|---|
| Empty commit | Don't create; suggest combining with next change |
| WIP commits | Suggest git commit --amend or squash before PR |
| Detached HEAD | Warn user; create branch git switch -c <name> |
| Diverged branches | Suggest git pull --rebase over git pull (merge) |
| Too many commits in PR | Suggest interactive squash before review |
| No recent tags | Start changelog from first commit |
| Monorepo | Scope commits to package: feat(api):, fix(web): |
Integration with CI/CD
Generated output is designed for CI/CD consumption:
- Commitlint config:
references/commitlint.config.js - Semantic Release config:
references/.releaserc.json - Changelog format: Compatible with
standard-version,semantic-release,git-cliff - PR template: GitHub/GitLab PR template format
Scripts
scripts/generate-changelog.sh— Generate changelog from git logscripts/next-version.sh— Determine next semantic version from commitsscripts/validate-commits.sh— Validate conventional commit compliance
References
references/conventional-commits-spec.md— Full Conventional Commits specreferences/keep-a-changelog-format.md— Keep a Changelog format guidereferences/semver-cheatsheet.md— Semantic Versioning reference