One of the first questions I always hear when talking about switching from GitFlow to Trunk-Based Development is “But how do we use our staging environment for testing?”

Of course, in an ideal world, testing in a staging environment is rarely, if ever needed. But most of us aren’t there yet. So how can we use a testing or staging environment, without that trusty staging branch you’re so familiar with?

The approach I advocate in my free Lean CD Bootcamp is to just pull the staging environment out of your workflow. That is, it’s no longer a step toward promotion to your mainline branch (usually called main or master).

What this means is that you can still push to your staging branch, when testing is necessary. But you never promote code from staging to anywhere else… instead, when you’re done with your feature, you merge it straight from your feature branch into mainline.

On paper, it looks almost the same. And perhaps more important, you don’t need to update your deployment automation scripts. Any push to the staging branch can still auto-deplo to your Staging environment, with no changes.

With this change in place, the staging branch becomes a throw-away, temporary sand box. You can force push to it at will (assuming nobody else is using it, anyway).

So let’s walk through a typical scenario.

You’ve recently started a new feature branch, off of master, made a few changes, and now you want to test it on Staging.

git checkout master
git checkout -b my-new-feature
#  Do some work
git add .
git commit -m "My awesome new code!"
git push -f origin my-new-feature:staging  # <--- Force push your changes to staging

Now you, or your QA team, or whomever, does some testing of your code on Staging, and they ask you to make some changes. Meanwhile, one of your colleagues has pushed new changes to main, which you also want to included. So you rebase your branch on top of master, make your changes, then once again force push everything to staging.

git checkout main
git pull # Pull down your colleague's changes
git checkout my-new-feature
git rebase main # Rebase your changes on top of the new main
# Make the changes discovered during testing
git add .
git commit -m "My awesome new changes"
git push -f origin my-new-feature:staging # <-- once again, staging has all of your changes

Notice there’s no ugly mess of merging things into staging then later into main, and trying to resolve conflicts multiple times, etc.