Can GitHub Flow be used for deploying to Development, Staging, and Production?

[Rod-at-DOH]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Workflow Deployment

Discussion Details

I've known about GitFlow and GitHub Flow for about two years now. But as time goes by, I understand both of them better than I did when I first learned about them.

Git Flow strikes me as an approach that would work well, if your company's approach is to always maintain a Development, Staging, and Production branches. When I work, we've been using GitHub Enterprise in our GitHub Organizations for 3 years, but we really haven't done this rigorously. Another thing which has been in place here for many years is having a Development, Test (or Staging), and Production environment. These haven't been enforced using repos with appropriately named branches. It's just been an approach which has been followed long enough that it's been in place before I was hired.

Then there is GitHub Flow, which is simpler and cleaner. Personally, I prefer this approach. I like the idea of having just one, long-lived branch, the default branch. Then as many feature branches as you need, but they all should (ideally) go away once they've been merged back in main. And I've been championing this approach for a long time, but it really hasn't been adopted where I work. I don't think people have understood GitHub Flow. Perhaps I haven't done a good enough job explaining it. But now I'm wondering if a big part of it is because the cultural mindset is we must always have a development, staging, and production environment. And without realizing it until now, the GitFlow approach seems better suited to the cultural approach followed here since time began (at least here).

But, as one last ditch effort to try and get GitHub Flow adopted, I'm wondering if a GitHub Flow branching and project management approach could still be used to deploy to Development, Staging, and Production environments?

[Rod-at-DOH]

Thank you for your response. I've got a question for clarification. It seems to me that a PR to main would launch both the Development and Staging deployments. Am I correct about that? I suppose that's OK. In our environment UAT (Staging) can go on for weeks, before the relevant people sign off.

One last thing, I am fine with a manual deployment to Production, but I do not think my colleagues will be on board with that. Over the last year, when learning more about GitHub Actions, the idea of automation has captured everyone's minds and hearts. In fact, that is what has held me back, because it took me months to figure out how to use Releases to capture documentation as to what the release is about. In the meantime, my colleagues have moved on with the scheme they developed when we were using TFS. Although, they use Environments in GitHub. At this point they've propagated their approach to 3 repos, whereas I am still learning how to do use GitHub Flow. And one of those 3 is a project I've been "leading". I told this one developer not to do it their old way, but he ignored my instruction (although I'm supposed to be the project lead) and just did it the old way. They approach is somewhat similar to GitFlow, but with some major differences. Here's their approach:

• There are 3 branches which MUST always exist, regardless of any other branches. Those 3 branches are: Development, UAT, and Production.
  • In fact, some have gone so far as to make the Production branch the default branch. If there is a main/master branch it must be ignored or even deleted.
• YAML files are written that incorporate PowerShell. The purpose of those workflows is to determine the name of the branch. Thus, why those 3 branches names MUST exist!!!
  • This is where the Environments come in. There are 3 Environments, named Development, UAT, and Production. Those environments specify where to deploy the apps and anything else related to deployment. Once the target branch is determined with PowerShell, then the details of that environment are applied.

The thing I didn't like about their approach, and the only time I've gain in changing their minds, is that there is no documentation as to what is in any deployment. I was certain that I could find a way. I did, when I found paulhatch/semantic-version@v5.4.0. However, it took me over a month to find it (I am working alone). Meanwhile they've going along adding a pattern they've used for years, amended to work in GitHub, to more and more repos. One of them does admit that a using Releases and being able to enter documentation as to what is in the release does have advantage. However, the one thing they are NOT willing to give up, is having an automated workflow for all deployments. And they've convinced management that having automated deployments and only automated deployments is, "how it is done on GitHub". My approach is to ask how people do deployments using GitHub Actions, rather than project what we've done in the past, onto GitHub and claim that is how people have always done deployments on GitHub.

Sorry, long diversion. The bottom line is certain approaches here are now sacrosanct. One of them is that deployments can only be done using automated workflows. No other approach is allowed.

[aftabhussainofficals]

Hey @Rod-at-DOH
Great question, and honestly you're not alone in this struggle,a lot of teams get stuck thinking their branching strategy has to mirror their environments.
The good news is yes, GitHub Flow works perfectly fine with Dev, Staging, and Production. The key mindset shift is this: environments are controlled by your deployment pipeline, not your branches.
Here's how it maps practically:

Dev environment => triggered when a PR is opened from any feature branch
Staging => triggered automatically when that PR gets merged into main
Production => triggered by cutting a Release or Tag from main when you're ready

So main stays clean and is always your single source of truth. No painful merge conflicts between long-lived branches, no GitFlow tax.
The feature that might really help you convince your team is GitHub Environments ,you can literally create three environments called Development, Staging, and Production right inside your repo settings. Then add deployment protection rules so Production requires a manual approval before anything gets pushed. That usually wins over the people who worry about losing control.
The honest truth is GitFlow feels safer to teams who are used to environment-per-branch thinking, but it creates way more complexity than it solves. GitHub Flow with proper CI/CD pipelines gives you the same control with far less overhead.
Hope this helps make the case ,good luck with the team!

[Rod-at-DOH]

Thank you for your response. I refer you to my response to radwanalmsora.

I do have some clarification questions:

• I'm sure that this is controlled in the on clause, but how do I specify that the PR to Dev is launched when opened from a feature branch? What's the keyword(s) I should use?
• This question is similar to the previous one, how do I specify triggering an automatic PR to merge into main related to the Staging environment?

As I said in my response to radwanalmsora I have a sheer rock face to scale trying to convince my coworkers and management to allow for manually triggering using either Release or Tag.

[legendONE382]

Is it free 😁🆓

[Rod-at-DOH]

😕

[aftabhussainofficals]

Dev trigger when a PR is opened from a feature branch:

deploy-dev.yml

synchronize covers new commits pushed to an already-open PR, and reopened handles re-opened PRs. Since in GitHub Flow all feature branches target main, this naturally fires only for feature-branch PRs no extra filtering needed.

Staging trigger automatically when a PR merges into main:
deploy-staging.yml

There's no special "merged" event keyword a merge is a push to main, so push on main is exactly right. GitHub doesn't expose a standalone merged trigger; this is the idiomatic way.
Full picture of all three in one place:

deploy-dev.yml

on:
pull_request:
types: [opened, synchronize, reopened]
branches: [main]

deploy-staging.yml

on:
push:
branches: [main]

deploy-production.yml <= the contentious one

on:
release:
types: [published]

OR

workflow_dispatch: # manual button trigger easier sell than releases

workflow_dispatch is worth mentioning to your team as a stepping stone it adds a literal "Run workflow" button in the GitHub UI, which gives the same manual control as a Release/Tag without requiring them to learn release management.

[Rod-at-DOH]

Thank you for this quick tutorial!

[onurdilmen]

Short answer: yes, and that's actually how most teams running GitHub Flow at scale do it. The trick is decoupling branching strategy from deployment strategy — those are two separate things and Git Flow conflates them.

In GitHub Flow you have one long-lived branch (main). Multi-env deploys come from GitHub Environments + workflow logic, not from branches.

A common mapping that works well:

Trigger	Deploys to	How
PR opened	ephemeral preview env	on: pull_request, deploy to a per-PR URL
Merge to main	Development	on: push to main
Tag v* or GitHub Release	Staging	on: release or tag filter
Manual approval on Staging	Production	Environment protection rules

Why this is better than Git Flow's develop / release / master setup:

• main is always shippable — no merge-train of release branches, no cherry-picking hotfixes back to develop.
• "What's in production right now?" maps to a tag or a deployment record, not "whichever branch a release manager remembered to update."
• Hotfixes are just PRs to main like everything else, plus a fast-forward deploy.

The piece your colleagues are probably missing: Environments

Repo → Settings → Environments → create development, staging, production. On production enable Required reviewers (the manual approval step) and optionally Deployment branches to restrict which refs can deploy there.

Then in the workflow:

jobs:
  deploy-dev:
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    environment: development
    runs-on: ubuntu-latest
    steps: [...]

  deploy-staging:
    if: github.event_name == 'release'
    environment: staging
    runs-on: ubuntu-latest
    steps: [...]

  deploy-prod:
    needs: deploy-staging
    environment: production   # this gates on manual approval
    runs-on: ubuntu-latest
    steps: [...]

environment: is the key word — it produces the Deployments timeline on the repo home, gates the job on the reviewers you configured, and lets each env have its own secrets (DB URLs, API keys per stage).

On the cultural side

The reason GitHub Flow doesn't stick at a lot of orgs isn't technical, it's that "we have dev/staging/prod" gets mentally collapsed with "we need a branch per environment". Separating those two conversations — "branches are about change isolation, environments are about deploy targets" — usually flips it. Show the team that main flowing into three environments through Environments protection gives them the same checkpoints they like about Git Flow, with less ceremony and fewer merge conflicts.

[Rod-at-DOH]

I didn't know about the concurrency. That is awesome! I don't know if we've had more than 1 PR trying to run at the same time, but I'm sure it may happen.

To answer your question, we're only using a self-hosted runner running on one of our servers, which I configured a few years back. Personally, I'd like to use some cloud, but that's going to be difficult sell.

[onurdilmen]

Self-hosted on one server is a perfectly reasonable spot to be in — especially if your deploys need direct network access to something on-prem (DB, internal API, a license server). The "let's move to cloud runners" pitch usually loses on cost ground for small teams; for the kind of volume most internal CI sees, GitHub-hosted Linux comes out to less than people expect, which is rarely the line item that turns heads.

But there are two self-hosted-specific things that matter way more once you layer Environments on top:

Workspace pollution. A single runner reusing _work/ across jobs can carry leftover state — node_modules from a previous run, half-applied migrations, env vars exported by an earlier step. actions/checkout@v4 cleans the repo dir by default but doesn't touch siblings. If you ever hit a "works on the second run, not the first" bug, that's almost always it. Either add a final cleanup step or run a wrapper script that nukes $RUNNER_WORKSPACE between major jobs.

Implicit env access. This is the big one. On GitHub-hosted runners, every job gets a fresh VM, so prod secrets can't leak into a staging job. On a single self-hosted runner, the same machine runs all three environments — meaning if a staging job ever gets compromised (a poisoned npm dep, a malicious PR action), it has filesystem-level access to whatever production left behind: cached credentials, SSH keys, ~/.aws/credentials. The clean mitigation is runner groups: org settings (or repo settings if it's a personal repo) → create a prod-runners group containing just that one machine, then restrict the production environment to that group. Combined with required reviewers, you get the same isolation cloud runners hand you for free.

On the cloud sell, fwiw: framing it as "let's move all CI to cloud" usually dies on cost or change-aversion. Framing it as "let's move only the prod deploy to a cloud runner so the self-hosted box never holds prod secrets" lands much better — it's a security argument, not a modernization one. The dev/staging workloads stay exactly where they are, and you get a clean break between the runner that knows about prod and the runner that doesn't.

[Rod-at-DOH]

WOW, I thought that self-hosted runners were better at separating one run from another! I thought that even a self-hosted runner would create a new VM to perform its action in, then blow that away once it was done. What you're saying suggests to me that my understanding may be wrong. FWIW, I've not seen any leakage such as you've described. But just because I haven't witnessed any leakage into a staging job doesn't mean that it won't happen.

Since we only have 1 server that acts as our self-hosted runner, I don't know how creating a runner group for that server would make any difference. My IT group would only be interested in my provisioning a new server to act as another self-hosted runner server, if the current one's resources are pushed to the limit, which they aren't.

Concerning moving anything to the cloud. I admit that during the COVID pandemic, I was very interested in moving everything to the cloud. Well, that didn't happen.

Now I'm more of the idea of let's move what we can to the cloud. What makes sense to move to the cloud. But that hasn't happened either. In the past there have been people who have scared upper management with the refrain, "Moving anything to the cloud will consume all our budget!!!". That argument plans very well here, and thus only one or two small things have moved to the cloud. Everything else is likely to always remain on-prem, because "we can do it better than any cloud vendor can".

[Rod-at-DOH]

Hi @onurdilmen I'm sorry to be so obtuse, but I'm not grokking what you mean in your deploy-dev job, where you use this at the beginning of the if statement: github.event_name == 'push'. I've implemented it in my repo where I'm learning how to use GitHub Flow with environments. and it worked, but since I've created a PR, how or maybe when would be the better term, does a push come in?

[Rod-at-DOH]

@onurdilmen my code, which you can see here, didn't work for the Staging environment. I'm guessing I've done something wrong in the workflow-2.yml.

[sabrinahaniff]

yeah github flow can totally work for dev, staging and production. I'd say the key thing is that your environments are controlled by your pipeline, not your branches. so you keep it simple with just main and feature branches but use github environments in your repo settings to handle the different stages

the way i'd set it up is something like: opening a pr from a feature branch triggers a deploy to dev, merging into main auto deploys to staging, and then production gets triggered by a release or tag so you have control over when things go live

the github environments feature is really what makes this work, you can add protection rules and require manual approvals before anything hits production which should help convince your team its not losing control, just moving the control to the pipeline instead of branches

[sabrinahaniff]

yea, that maps perfectly! You’d set up github environments with required reviewers for the UAT step, so nothing can move to production until someone manually approves it in github. keeps your exact dev -> uat -> prod process, just automates the handoffs between them

[Rod-at-DOH]

So then, I see if working like this. A GitHub workflow will automate the deployment to UAT, but doing a deployment to Production would require a manual step and using workflow_dispatch. Am I interpreting what you're suggesting correctly, or is that manual approval achieved differently?

[sabrinahaniff]

almost.. the manual approval is actually done through github environments, not workflow_dispatch. you go to repo settings -> environments -> create a “production” environment and add required reviewers there. then when the workflow tries to deploy to production it pauses and waits for someone to approve it in github before continuing. workflow_dispatch is more for manually triggering a workflow to run, its slightly different

[Rod-at-DOH]

Ah, I see. Yeah, I was confused by the use of "manual". I suppose that could be done using CODEOWNERS file or specifying that in the PR. However it is done, the PR will deploy to UAT and also try to deploy to Production but wait until the person/people identified to review it have finished reviewing and approving. I'm guessing that PR to Production will stay in effect until someone approves it. And if some issue is revealed in UAT testing, then we can cancel the PR to Production.

[sabrinahaniff]

yep! the deployment to production will just sit there waiting until the required reviewers approve it, and if something fails in UAT you can cancel the deployment before it ever reaches prod

[herumane0]

Yes GitHub Flow can still support Dev/Staging/Prod if you keep main as the single source of truth and use deployments/promotions or release tags instead of long-lived branches; this keeps the flow simple while still matching environment needs, similar to how an MP4 video compressor reduces complexity by handling optimization without changing the original workflow structure.

[Rod-at-DOH]

I have been working on implementing what so many of you have said here, to learn how to use GitHub Flow. To that end I've created a simple repo which I made public, called Explore-Environments. I'm using 3 YAML files, somewhat tied to environments.

One thing I've noticed is that all 3 YAML files ran, although the one for Production environment waited for me, since I had set that up in the Production environment to require a reviewer (me). And this is in keeping with what's been said in this forum thread. Note: that at this point I've only implemented the Production environment. I want to do both Develop and Staging next, for my edification.

One thing I am not clear on is why did Workflow 3 run twice? I'm guessing it has something to do with how I structured the workflow-3.yml file.

[Rod-at-DOH]

I have gotten great feedback to my question. I wish I could mark all of you who've added to my understanding on this topic, but I don't think that's possible. So, I'm going to select the first answer and mark it as "the answer" but know I would select you all for your answer, if I could.

Also, note that I am going to close this question as having been answered.

I've got some follow-up questions, but I don't think it is right for me to tack them onto this question. I'll reference this question in my follow-up posts.