Git Workflow
Quick Reference
- When to use: Every git commit, push, and pull request
- Enforcement: Required - consistent Git practices
- Impact if violated: High - messy history, broken CI
The Rule
Follow conventional commits, use feature branches, and verify before pushing.
Required Workflow
- Create a feature branch from
main - Make code changes
- Run verification:
pnpm run format && pnpm turbo build && pnpm test - Stage and commit with a conventional commit message
- Push and create a pull request
- Merge to
mainafter review
Commit Message Standards
Follow Conventional Commits:
<type>(<scope>): <subject>Types
feat:New featurefix:Bug fixdocs:Documentation onlystyle:Code style (formatting)refactor:Code restructuringtest:Adding/updating testschore:Maintenance tasks
Examples
Correct
bash
git commit -m "feat: add S3 upload retry mechanism"
git commit -m "fix(core): resolve middleware chain execution order"
git commit -m "refactor(database): extract query metrics to shared utility"
git commit -m "docs: update entity query guide"
git commit -m "test(aws): add integration tests for DynamoDB operations"
git commit -m "chore: update dependencies"Incorrect
bash
# Too vague
git commit -m "update"
git commit -m "changes"
git commit -m "fix stuff"
# Not conventional commits format
git commit -m "Added the new feature for users"
git commit -m "Fixed bug"Pre-Commit Verification
Required Checks
bash
# 1. Format code
pnpm run format
# 2. Lint code
pnpm run lint
# 3. Build all packages
pnpm turbo build
# 4. Run tests
pnpm testBranch Management
Branch Naming
Use descriptive, lowercase, hyphen-separated names with a type prefix:
bash
# Good branch names
feat/user-authentication
fix/memory-leak-webhook
refactor/database-queries
chore/update-dependencies
docs/entity-query-guide
# Poor branch names
feature_user_auth # Use hyphens, not underscores
FixMemoryLeak # Use lowercase
new-stuff # Be specificWorking with Worktrees
For parallel feature development, use git worktrees:
bash
# Create worktree with feature branch
git worktree add -b feat/my-feature ~/wt/my-feature main
# Work in the worktree
cd ~/wt/my-feature
pnpm install
# After merge, cleanup
cd /path/to/mantle
git worktree remove ~/wt/my-feature
git branch -d feat/my-featureWorktree Benefits
- Isolation - Changes don't affect main until merged
- Multiple features - Work on several features simultaneously
- Safe experimentation - Easy to discard failed attempts
Pull Request Guidelines
PR Title
Same as commit message format:
- Follow conventional commits
- Keep concise and descriptive
PR Description Template
markdown
## Summary
Brief description of changes
## Changes Made
- Specific change 1
- Specific change 2
## Testing
- [ ] Unit tests pass (`pnpm test`)
- [ ] Build succeeds (`pnpm turbo build`)
- [ ] Lint passes (`pnpm run lint`)
- [ ] Format checked (`pnpm run format:check`)
## Checklist
- [ ] Code follows project conventions
- [ ] Documentation updated if needed
- [ ] Tests added/updatedMonorepo Considerations
Turborepo Integration
Turborepo caches build outputs. After making changes:
bash
# Build only affected packages (Turborepo handles dependency graph)
pnpm turbo build
# Build a specific package
pnpm turbo build --filter=@mantleframework/core
# Run tests for specific package
pnpm turbo test --filter=@mantleframework/awsChangesets
For versioning and changelogs:
bash
# Create a changeset describing your changes
pnpm changeset
# Follow prompts to select packages and bump typeEnforcement
Automated
- CI Pipeline - Build, lint, test on every PR
- Turborepo - Ensures dependency graph is respected
Code Review Checklist
- [ ] Conventional commit format used
- [ ] Clean, professional messages
- [ ] All tests pass
- [ ] Code formatted with dprint
- [ ] Code linted with ESLint
- [ ] Feature branch (not direct to main)
Related Patterns
- Code Comments - Git as source of truth for code history
- Naming Conventions - Branch and file naming standards
- Code Formatting - Pre-commit formatting checks
Consistent Git practices keep the repository clean and maintainable. Follow conventional commits and always verify before pushing.