ChatGPT Git Workflow & Version Control Guide Prompt
You are a senior engineering lead who has defined Git workflows for teams from 2 to 200 developers.
Category
💻 Coding
Difficulty
Intermediate
Models
3
Last Updated
2026-06-28
Works with
📄 Example output
⚠️ Common Mistakes
❓ FAQ
⚙️ Fill in your variables
📋 Prompt
You are a senior engineering lead who has defined Git workflows for teams from 2 to 200 developers.
Team: [team size — solo/2–5/5–20/20+]
Project: [project type — web app/library/monorepo/open source]
Problem: [current git problem — messy history/merge conflicts/unclear branching/slow releases]
Deployment: [deployment frequency — multiple per day/weekly/per sprint]
Task: Design a complete Git workflow:
1. BRANCHING STRATEGY: Which model (GitFlow/GitHub Flow/Trunk-based) and why for your team
2. BRANCH NAMING CONVENTION: Exact naming pattern with examples
3. COMMIT MESSAGE STANDARD: Format + examples (good and bad)
4. PULL REQUEST TEMPLATE: What every PR must include
5. MERGE STRATEGY: Merge vs. Squash vs. Rebase — which and when
6. COMMON COMMANDS: 10 git commands your team should know with examples
7. WORST MISTAKES: Top 5 git disasters and how to prevent/recover from each
Team: [team size — solo/2–5/5–20/20+]
Project: [project type — web app/library/monorepo/open source]
Problem: [current git problem — messy history/merge conflicts/unclear branching/slow releases]
Deployment: [deployment frequency — multiple per day/weekly/per sprint]
Task: Design a complete Git workflow:
1. BRANCHING STRATEGY: Which model (GitFlow/GitHub Flow/Trunk-based) and why for your team
2. BRANCH NAMING CONVENTION: Exact naming pattern with examples
3. COMMIT MESSAGE STANDARD: Format + examples (good and bad)
4. PULL REQUEST TEMPLATE: What every PR must include
5. MERGE STRATEGY: Merge vs. Squash vs. Rebase — which and when
6. COMMON COMMANDS: 10 git commands your team should know with examples
7. WORST MISTAKES: Top 5 git disasters and how to prevent/recover from each
GIT WORKFLOW: 5-person web app team, weekly deployments
BRANCHING STRATEGY: GitHub Flow (simplified)
Why: GitFlow is overkill for teams under 20. Trunk-based needs mature CI/CD. GitHub Flow matches your weekly release cadence and team size perfectly.
RULES:
• main = always deployable
• Every change = feature branch from main → PR → review → merge to main
• Deploy from main on a schedule or when ready
BRANCH NAMING:
feat/[ticket]-[short-description] → feat/TN-142-add-prompt-search
bug/[ticket]-[short-description] → bug/TN-198-fix-copy-button-mobile
hotfix/[description] → hotfix/security-patch-api-auth
chore/[description] → chore/update-dependencies-june
COMMIT MESSAGE FORMAT (Conventional Commits):
type(scope): short description (under 72 chars)
Good: feat(prompts): add variable fill-in UI to prompt detail page
Good: fix(auth): prevent token expiry on page refresh
Bad: 'fixed stuff'
Bad: 'WIP'
Bad: 'update'
Types: feat | fix | docs | style | refactor | test | chore
PR TEMPLATE:
## What does this PR do?
[1–2 sentence summary]
## Why?
[Link to ticket/issue]
## Testing
[ ] Unit tests pass
[ ] Tested on mobile
[ ] No console errors
## Screenshots (if UI change)
MERGE STRATEGY: Squash merge to main
Why: Keeps main history clean (one commit per feature), while preserving full history in the feature branch while it's open.
TOP 5 GIT DISASTERS:
1. Pushed secrets to public repo
Prevention: git-secrets pre-commit hook + .gitignore for .env
Recovery: Rotate credentials IMMEDIATELY (assume compromised), then git filter-branch or BFG Repo Cleaner
2. Force-pushed main and lost commits
Prevention: Branch protection rules on main (required reviews, no force push)
Recovery: git reflog — your commits exist in reflog for 90 days
BRANCHING STRATEGY: GitHub Flow (simplified)
Why: GitFlow is overkill for teams under 20. Trunk-based needs mature CI/CD. GitHub Flow matches your weekly release cadence and team size perfectly.
RULES:
• main = always deployable
• Every change = feature branch from main → PR → review → merge to main
• Deploy from main on a schedule or when ready
BRANCH NAMING:
feat/[ticket]-[short-description] → feat/TN-142-add-prompt-search
bug/[ticket]-[short-description] → bug/TN-198-fix-copy-button-mobile
hotfix/[description] → hotfix/security-patch-api-auth
chore/[description] → chore/update-dependencies-june
COMMIT MESSAGE FORMAT (Conventional Commits):
type(scope): short description (under 72 chars)
Good: feat(prompts): add variable fill-in UI to prompt detail page
Good: fix(auth): prevent token expiry on page refresh
Bad: 'fixed stuff'
Bad: 'WIP'
Bad: 'update'
Types: feat | fix | docs | style | refactor | test | chore
PR TEMPLATE:
## What does this PR do?
[1–2 sentence summary]
## Why?
[Link to ticket/issue]
## Testing
[ ] Unit tests pass
[ ] Tested on mobile
[ ] No console errors
## Screenshots (if UI change)
MERGE STRATEGY: Squash merge to main
Why: Keeps main history clean (one commit per feature), while preserving full history in the feature branch while it's open.
TOP 5 GIT DISASTERS:
1. Pushed secrets to public repo
Prevention: git-secrets pre-commit hook + .gitignore for .env
Recovery: Rotate credentials IMMEDIATELY (assume compromised), then git filter-branch or BFG Repo Cleaner
2. Force-pushed main and lost commits
Prevention: Branch protection rules on main (required reviews, no force push)
Recovery: git reflog — your commits exist in reflog for 90 days
🏆
💡 Pro Tips
Best model for this prompt
Claude
Claude (Opus 4 / Sonnet 4)
Branch protection rules on main are non-negotiable — require at least 1 review, disable direct pushes
Write commit messages as if the future you has no context — 'fix bug' is useless; 'fix login redirect loop when session expires' is useful
Squash merge for features keeps history clean; preserve full history only when you need it for debugging
`git stash` before switching branches — uncommitted work on the wrong branch causes most beginner git panics
Committing directly to main — even for solo projects, PRs catch errors and create a paper trail
Enormous commits ('added everything') — small atomic commits make code review easier and bugs easier to isolate
Not using .gitignore from project start — adding it later when node_modules is already tracked is painful
Merge conflicts that grow for weeks — merge main into your branch at least every 2–3 days to minimise conflict surface area
- GitFlow vs. GitHub Flow vs. Trunk-based — which should I use?Trunk-based: best for CI/CD teams deploying multiple times per day (requires strong testing). GitHub Flow: best for teams with clear feature cycles and weekly-monthly releases. GitFlow: best for products with formal versioned releases (libraries, mobile apps). Most teams should use GitHub Flow.
- When should I rebase vs. merge?Rebase your feature branch onto main (rebase main onto feature) to keep your branch up to date and have a clean history. Merge (not rebase) from feature to main at PR time. Never rebase branches that others are working on — it rewrites history they depend on.
- How do I undo a commit?If not pushed: `git reset HEAD~1` (soft — keeps changes staged) or `git reset HEAD~1 --hard` (hard — discards changes). If pushed to a non-protected branch: `git push --force-with-lease` after reset. If on main: `git revert [commit-hash]` (creates a new commit undoing the change — safer).
- What's the best way to handle long-running feature branches?Avoid them. Long-running branches = diverging from main = painful merge conflicts. Instead: use feature flags (ship code but hide the feature), break the feature into smaller shippable chunks, or merge 'work in progress' stubs that don't break existing functionality.