Development environments are where branching tends to click for most teams. Instead of sharing a single mutable database, each workflow gives developers isolation by default while keeping environments closely aligned with production.
Teams often combine more than one of the patterns below, depending on team size and how much parallel work is happening.
One branch per developer

This is one of the most common workflows. Each engineer gets their own development branch, typically created directly from production, or from an anonymized version of production if PII is involved. This gives you:
- Isolation: no stepping on each other’s changes
- Production-like data: the branch starts from real state
- Low overhead: no storage duplication, and compute can be very small
Because branches are lightweight and scale to zero when idle, this pattern remains affordable even as the team grows.
If production contains PII, the flow stays the same - you simply derive developer branches from an anonymized branch instead of production.

Shared development branch

A variation of the above is to maintain a single shared development branch. This works well for smaller teams or projects where changes are more sequential than parallel. The dev branch is typically derived from production (or from an anonymized production branch) and used as the main environment for ongoing work.
Like staging, this branch is relatively long-lived, but it still needs to stay in sync with production. Teams periodically reset it to the parent branch to avoid drift. This approach:
- Reduces the number of active branches to manage
- Works well when coordination is easy
- Still avoids touching production directly
One branch per pull request

In this setup, every pull request automatically gets its own database branch. The branch is created when the PR opens and deleted when the PR is merged or closed. This gives you:
- Fully isolated environments for each change
- A safe place to run migrations specific to the PR
- End-to-end testing against realistic data
If you already have a staging branch, PR branches are often derived from staging. If not, they can be derived directly from production or from an anonymized production branch.









