| name | common-git |
| description | Git commit messages, PR workflow, and branching strategy using Conventional Commits and Semantic Versioning. Use when creating commits, pull requests, or managing Git workflow. |
| user-invocable | false |
Git Conventions
This skill defines Git commit and PR conventions.
Commit Message Format
Use Conventional Commits format:
<type>(<scope>): <subject>
<body>
Types
- feat: New feature for the user
- fix: Bug fix for the user
- docs: Documentation changes
- style: Code formatting (no logic changes)
- refactor: Code refactoring (no behavior changes)
- test: Adding or updating tests
- chore: Build process, dependencies, tooling
- BREAKING CHANGE: Introduces breaking changes
Examples
feat(sdk-dotnet): add Azure Key Vault provider
Implements ISecretProvider for Azure Key Vault using
DefaultAzureCredential. Supports vault URL from $config
and EnvilderOptions override.
Closes
fix(cli): correct map file path resolution on Windows
The map file path was not being resolved correctly when using
backslashes. This fix normalizes paths cross-platform.
refactor(core): extract provider factory to shared module
Moves provider selection logic from CLI and GHA startup into
shared ContainerConfiguration for consistency.
Commit Guidelines
- Separate subject from body with a blank line
- Limit subject line to 50 characters
- Capitalize subject line
- No period at end of subject
- Use imperative mood ("add" not "added")
- Wrap body at 72 characters
- Explain what and why, not how
Pull Request Workflow
PR Title
Follow same convention as commits:
feat(groups): add collaborative group ownership
PR Description Template
## Description
Brief description of changes
## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update
## Changes Made
- Added X functionality
- Updated Y component
- Fixed Z issue
## Screenshots (if applicable)
## Checklist
- [ ] Code follows project conventions
- [ ] Tests added/updated
- [ ] Documentation updated
- [ ] Build passes locally
- [ ] No breaking changes (or documented)
Merge Strategy
Use Squash and Merge to keep main branch clean:
- All commits in PR squashed into single commit
- Commit message follows conventional commits
- History remains linear and readable
Branching Strategy
Trunk-Based Development
- main - Production-ready code
- {usergithub}/{type}/{name} - All work branches (short-lived)
Branch Naming
macalbert/feat/add-azure-provider
macalbert/fix/windows-path-resolution
macalbert/refactor/extract-provider-factory
macalbert/docs/add-nodejs-sdk-references
Workflow
- Create branch from
main
- Make small, frequent commits
- Push to remote frequently
- Open PR when ready
- Get approval from team member
- Squash and merge to
main
- Delete feature branch
- Tag release if deploying
Tagging Releases
Use Semantic Versioning:
vMAJOR.MINOR.PATCH
- MAJOR: Breaking changes
- MINOR: New features (backward compatible)
- PATCH: Bug fixes (backward compatible)
Examples tag
git tag -a v2.1.0 -m "Release v2.1.0 - Add group coupons feature"
git push origin v2.1.0
Summary
- Conventional Commits for all commits
- Squash and merge for PRs
- Trunk-based development on main
- Semantic versioning for releases
- Short-lived branches (delete after merge)
- Descriptive PR titles and descriptions
When working with Git:
- Use conventional commits format
- Write descriptive commit messages
- Create focused, small PRs
- Get code reviews before merging
- Squash and merge to main
- Delete branches after merge
- Tag releases with semantic versioning
