Knowledge > Runbooks > Agent Ops > Git Safety Rules for Multi-Agent Workflows
Git Safety Rules for Multi-Agent Workflows
Multiple Claude agents may be working concurrently across sessions. Follow these rules to prevent one agent's work from destroying another's.
The Core Rules
- Always create your own branch — never work directly on
mainormaster - Never reuse another agent's branch — if you're on someone else's branch, create a new one
- Never
git push --force— this destroys other agents' pushed commits - Always rebase before pushing — prevents conflicts on the deploy branch
- If a conflict resolution is unclear, ask the founder before pushing
Branch Naming
Use the pattern feat/short-description or fix/short-description:
feat/chatbot-fallback-llm
feat/pewsearch-premium-pages-redesign
fix/stripe-webhook-trial-end
chore/update-product-knowledge-pricing
Deploy Branches by Codebase
| Codebase | Deploy Branch |
|---|---|
churchwiseai-web/ | main |
pewsearch/web/ | master |
sermon-illustrations/ | master |
Step-by-Step: Starting Work
-
Check out and update the deploy branch
# For churchwiseai-webcd /c/dev/churchwiseai-webgit checkout maingit pull origin main# For pewsearch or sermon-illustrationscd /c/dev/pewsearch/webgit checkout mastergit pull origin master -
Create your own feature branch
git checkout -b feat/my-task-description -
Confirm you're on your new branch before making any changes
git branch --show-current# Should show: feat/my-task-description
During Work: Committing
Commit frequently with clear messages:
git add src/app/api/chatbot/stream/route.ts
git commit -m "feat: add fallback to GPT-4o-mini when Haiku unavailable"
Use the /commit skill for structured commit messages that follow the portfolio conventions.
Finishing Work: Merging and Pushing
-
Fetch and rebase before pushing
git fetch origingit rebase origin/main # or origin/master -
Resolve any conflicts, then continue the rebase:
# After resolving each conflicted file:git add [conflicted-file]git rebase --continueIf the conflict is in a file you don't fully understand, STOP and ask the founder. Do not guess at conflict resolution in business-logic files.
-
Push your feature branch
git push origin feat/my-task-description -
Merge to the deploy branch
git checkout maingit pull origin maingit merge feat/my-task-descriptiongit push origin mainOr create a PR via
gh:gh pr create --title "feat: my task description" --base main -
Delete your feature branch after merging
git branch -d feat/my-task-descriptiongit push origin --delete feat/my-task-description
Checking What Other Agents Have Done
Before starting work, check what branches currently exist on the remote:
git fetch origin
git branch -r
If you see a branch like feat/chatbot-redesign that is close to your task, check with the founder whether that work is complete or in progress before creating overlapping work.
Emergency: I Pushed to main/master Directly
If you accidentally pushed to the deploy branch without going through a feature branch:
- Do NOT
git push --forceto undo it - Check what you pushed:
git log origin/main -5 - If it is safe (correct, no conflicts), leave it and note it in DECISION_LOG.md
- If it is wrong, create a new commit that reverts the change:
git revert [commit-hash]
What NOT to Do
# NEVER
git push --force
git push --force-with-lease # still potentially destructive in multi-agent context
git push origin main # without first fetching and rebasing
git checkout main && git merge # without confirming the deploy branch is current
Verification
git log origin/main -5shows your commit at the top with the correct message- The deployed site reflects your changes (after Vercel auto-deploys from the push)
- No other agent's work has been overwritten (compare branch history if uncertain)