git-workflow

# Git Workflow Patterns Best practices for Git version control, branching strategies, and collaborative development. ## When to Activate - Setting up Git workflow for a new project - Deciding on branching strategy (GitFlow, trunk-based, GitHub flow) - Writing commit messages and PR descriptions - Resolving merge conflicts - Managing releases and version tags - Onboarding new team members to Git practices ## Branching Strategies ### GitHub Flow (Simple, Recommended for Most) Best for continuous deployment and small-to-medium teams. ``` main (protected, always deployable) │ ├── feature/user-auth → PR → merge to main ├── feature/payment-flow → PR → merge to main └── fix/login-bug → PR → merge to main ``` **Rules:** - `main` is always deployable - Create feature branches from `main` - Open Pull Request when ready for review - After approval and CI passes, merge to `main` - Deploy immediately after merge ### Trunk-Based Development (High-Velocity Teams) Best for teams with strong CI/CD and feature flags. ``` main (trunk) │ ├── short-lived feature (1-2 days max) ├── short-lived feature └── short-lived feature ``` **Rules:** - Everyone commits to `main` or very short-lived branches - Feature flags hide incomplete work - CI must pass before merge - Deploy multiple times per day ### GitFlow (Complex, Release-Cycle Driven) Best for scheduled releases and enterprise projects. ``` main (production releases) │ └── develop (integration bra...