Daniel Cohen·
Designed a trunk-based workflow with squash merges and a feature-flag escape hatch for our team of 6
Optimize Git workflows with branch strategies, commit conventions, PR templates, merge rules, and CI integration for team efficiency.
Git Workflow Optimizer
You are a Git workflow architect and DevOps engineer. Design an optimized Git workflow for the following team and project.
**Team Size & Structure:**
{{team_structure}}
**Project Type:**
{{project_type}}
**Release Cadence:**
{{release_cadence}}
**Current Workflow Issues:**
{{current_issues}}
**Platform:**
{{git_platform}}
**CI/CD Requirements:**
{{cicd_requirements}}
Design:
1. **Branching Strategy**: Choose and document the best strategy (GitFlow, GitHub Flow, trunk-based) with diagrams
2. **Branch Protection Rules**: Required reviews, status checks, signed commits
3. **Commit Convention**: Commit message format (Conventional Commits), linting rules
4. **PR Templates**: Standardized pull request templates with checklist
5. **Merge Strategy**: Squash vs rebase vs merge commit rules per branch type
6. **Release Process**: Version tagging, release notes generation, changelog automation
7. **Hotfix Procedure**: Step-by-step emergency patch process
8. **CI Integration**: Git hooks and CI triggers for linting, testing, building
9. **Automation**: GitHub Actions/GitLab CI for auto-labeling, auto-assigning, stale PR management
10. **Rollback Plan**: How to quickly revert problematic changes
11. **Team Onboarding**: Quick reference guide for new team members
12. **Repository Hygiene**: Cleanup policies for old branches, artifact retention
Output complete configuration files, templates, and documentation.
Ergebnisse
Designed a trunk-based workflow for a 6-engineer team shipping a SaaS app multiple times a day. The pain was long-lived feature branches and messy merge conflicts — trunk-based with short branches and feature flags fixes both.
## Branching model
```
main (always deployable)
├── feat/checkout-retry (lives < 2 days, squash-merged)
└── fix/null-coupon (hotfix → main → cherry-pick if release branch exists)
```
Short-lived branches off `main`, merged via squash within 48h. Risky work hides behind a feature flag, not a long branch.
## Branch protection (main)
- Require 1 approving review + passing status checks.
- Require linear history (squash or rebase merges only).
- Dismiss stale approvals on new commits.
## Conventional Commits
```
feat(checkout): add gateway retry with backoff
fix(coupon): handle unknown code without 500
```
Enforced by a commit-msg hook (`commitlint`). This drives automated changelog + semver release notes.
## PR template (`.github/pull_request_template.md`)
```markdown
## What & why
## Testing done
- [ ] unit + integration green
- [ ] manual smoke
## Risk / rollback
```
**Merge rule:** squash to `main` (one logical commit per PR), merge-commit only for release branches. **Hotfix path:** branch from `main`, fix, fast-track review, merge, deploy; if a frozen release branch exists, cherry-pick. **Hygiene:** a scheduled action deletes merged branches and flags PRs stale after 7 days.
Modell: Claude Sonnet 4
14 Likes6 SavesScore: 9
1 Kommentar
Marco Rossi·
Tried it against a gnarly legacy file and it untangled it cleanly.