Branch deploys

Deploy feature branches to test environments before merging to production

Why branch deploys are better

Traditional deployments follow a “merge then deploy” pattern, merging multiple branches into a release branch and then deploying it all at once.

This can lead to many potential problems:

Branch deploys solve these issues by reversing the order: deploy first, then merge. This small change has big benefits.

Most importantly, we can safely deploy branches assuming they meet a small set of criteria:

Safer releases

Test your changes in production while main stays clean. If something breaks, your main branch remains stable and ready for other deploys.

Simple rollbacks

No need for complex revert commits. Just redeploy main and your system returns to a known good state.

Clear ownership

The developer who wrote the code stays responsible through deployment. No more “throwing code over the wall” to ops teams.

Better visibility

Every deploy is tracked and visible to the team. You always know what’s running and who deployed it.

Branch deploys fit naturally into your development workflow:

Choose how you want to deploy:

This workflow emerged from years of experience at GitHub and successfully scaled to hundreds of developers.

The key benefits of branch deploys on fast moving teams:

Small, frequent deploys reduce risk. They’re easier to verify and roll back if needed.

Complete code review before deploying. Use this time to catch issues before they hit production.

Keep code authors responsible for deployments. They know the code best and can respond quickly if issues arise.

Use Slack to keep your team informed about deploys. Good communication prevents deploy conflicts and helps everyone learn from issues.