macalbert/envilder/common-git

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 #85

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

1. Separate subject from body with a blank line
2. Limit subject line to 50 characters
3. Capitalize subject line
4. No period at end of subject
5. Use imperative mood ("add" not "added")
6. Wrap body at 72 characters
7. 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)
![Screenshot](url)
 
## 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

1. Create branch from main
2. Make small, frequent commits
3. Push to remote frequently
4. Open PR when ready
5. Get approval from team member
6. Squash and merge to main
7. Delete feature branch
8. 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

# Create tag
git tag -a v2.1.0 -m "Release v2.1.0 - Add group coupons feature"
 
# Push tag
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:

1. Use conventional commits format
2. Write descriptive commit messages
3. Create focused, small PRs
4. Get code reviews before merging
5. Squash and merge to main
6. Delete branches after merge
7. Tag releases with semantic versioning