Dev Git Workflow and Branch Strategy
====================================

Create a Git workflow and branching strategy guide for [team/project].

Team details:
- Team size: [number of developers]
- Release frequency: [daily/weekly/sprint-based]
- Current problems: [merge conflicts/unclear process/broken main]
- CI/CD: [yes/no]
- Deployment: [single/multiple environments]

GIT WORKFLOW GUIDE

1. BRANCH STRATEGY

   RECOMMENDED: GITHUB FLOW (for continuous deployment)
   - main: [always deployable]
   - feature branches: [short-lived from main]
   - No develop branch needed
   - Deploy from main

   ALTERNATIVE: GITFLOW (for scheduled releases)
   - main: [production code]
   - develop: [integration branch]
   - feature/*: [new features]
   - release/*: [release preparation]
   - hotfix/*: [production fixes]

2. BRANCH NAMING
   Format: [type/ticket-description]
   
   Types:
   - feature/: [new functionality]
   - bugfix/: [bug fixes]
   - hotfix/: [urgent production fixes]
   - chore/: [maintenance/refactoring]
   - docs/: [documentation only]

   Examples:
   - feature/TICKET-123-user-authentication
   - bugfix/TICKET-456-fix-login-redirect
   - hotfix/payment-null-pointer-exception

3. COMMIT MESSAGES

   FORMAT: [type(scope): description]

   Types:
   - feat: new feature
   - fix: bug fix
   - docs: documentation
   - style: formatting
   - refactor: code restructure
   - test: adding tests
   - chore: maintenance

   Examples:
   - feat(auth): add OAuth2 login with Google
   - fix(cart): resolve quantity not updating on removal
   - docs(api): update endpoint documentation

4. PULL REQUEST PROCESS

   PR REQUIREMENTS
   ☐ Linked to ticket/issue
   ☐ Description explains what and why
   ☐ Self-reviewed before requesting review
   ☐ Tests added/updated
   ☐ No debug code or commented code
   ☐ CI pipeline passing

   PR TEMPLATE
   ```markdown
   ## What
   [Brief description of changes]

   ## Why
   [Reason for change — link to ticket]

   ## How to test
   [Steps to verify the change]

   ## Screenshots (if UI change)
   ```

5. CODE REVIEW EXPECTATIONS
   - Review within: [1 business day]
   - Required approvals: [1-2]
   - Who can merge: [author after approval / reviewer]
   - Review focus: [correctness/security/maintainability]

6. MERGE STRATEGY
   - Squash and merge: [keeps main history clean]
   - Merge commit: [preserves full history]
   - Rebase: [linear history — requires discipline]
   - Recommendation: [squash for features/merge for releases]

7. PROTECTION RULES FOR MAIN
   - Require PR before merging: YES
   - Require CI to pass: YES
   - Require reviews: [number]
   - No force push: YES
   - Dismiss stale reviews on new commits: YES

Source: https://promptzyo.com/prompt/dev-git-workflow-and-branch-strategy