GitHub workflow for deploying features safely to production

Deploy with confidence using a clear GitHub workflow. This guide shows how to move work from a development branch to staging, then to production, while protecting end users. You’ll see how tools like Linear, Vercel, and Lovable support feature-by-feature development, detailed pull requests, and safe QA before release.

Why use development, staging, and production branches?

A three-branch workflow keeps users safe and your team organized. You build on a development branch, test in a staging environment, then merge into production only after checks. This prevents surprises and encourages predictable releases.

• Protect end users. Test before release.
• QA every change. Verify features on staging.
• Work incrementally. Prefer small, focused branches.
• Track clearly. Use descriptive PRs and notes.

What tools integrate with GitHub for smoother flow?

Choosing tools with strong GitHub integration streamlines tasks, tracking, and reviews.

• Linear: generates a branch name from a ticket and moves it to in progress. Helpful for task tracking.
• Lovable: switch branches in project settings. You can create branches there or in GitHub.
• Vercel: auto-deploys preview links on PRs and production builds after merges.
• CLI or UI: open PRs in GitHub UI or Terminal, based on preference.

How to create a feature branch and keep changes small?

Start from a ticket. Create a feature branch (often using the Linear ID). Switch to that branch in Lovable or GitHub and make focused updates. Keep scope tight: small changes are easier to test and merge. Avoid huge PRs with many unrelated edits.

• Name branches clearly. Use the ticket reference.
• Limit scope. One feature or improvement per branch.
• Stop early. Merge once the feature is complete, not after many extras.

How to prompt design changes with clear context?

If improving UI, provide the system with user feedback and goals. For example, apply Dieter Rams’s design principles to the dashboard to simplify and focus on function over form. Include what users found hard to understand so the assistant can suggest targeted changes.

How to open pull requests and deploy to staging and production?

Open a PR from your feature branch into staging first. Make the base/target staging, not production. Write a detailed description so teammates or your future self can understand changes without digging through code. Assign reviewers if needed. Vercel will provide a preview deployment so you can validate before merging.

• Open PR to staging. Set base to staging. Confirm “one commit ahead of main” if applicable.
• Describe thoroughly. Summarize changes, add screenshots if helpful.
• Review and test. Check files changed and the Vercel preview link.
• Merge and clean up. Confirm merge. Delete the feature branch to keep the repo tidy.
• Switch to staging in Lovable. Verify changes live on staging.

After staging is verified, run a QA check. When everything looks good, open a PR from staging to main (production). Vercel will auto-deploy and GitHub will run checks. Merge when there are no conflicts. Keep the staging branch for future work; do not delete it.

• Production PR. From staging to main with a brief, descriptive summary.
• Automated checks. Use Vercel deploy status and GitHub checks.
• Merge to release. Users receive the updates once production deploy succeeds.
• Record decisions. Favor overwriting rather than underwriting to leave a breadcrumb trail.

Have a question or a tip about PR descriptions, previews, or branch hygiene? Share your experience and doubts to keep improving this workflow.