We have two main branches here, master and development, and feature/bugfix branches come off of development. The issue we're having here is that we can't just merge development into master when doing a production deployment, because it's not guaranteed that those changes are thoroughly tested. What we've been doing is cherry picking changes from development into master, but that's a nightmare because sometimes changes depend on prior changes, so the code could wind up with compile errors if for instance I have PRs 1 and 2 and 2 contains a reference to a function added in 1, but we only want to deploy 2. This is especially bad because this is a VB.NET WebForms project, so compile errors don't always show up until runtime...

  • Use pull requests? Nov 14, 2019 at 15:58
  • Do your testing on your production branch. Test and deploy the same artefacts.
    – Ant P
    Nov 14, 2019 at 15:59
  • @AntP: What production branch? Did you mean "create a production branch?" Nov 14, 2019 at 16:00
  • @RobertHarvey no, I meant the branch that is being deployed into production. In this case, master.
    – Ant P
    Nov 14, 2019 at 16:00
  • 2
    A "staging" branch is probably a better idea. The code can be tested there, before it is pushed to master. Nov 14, 2019 at 16:02

2 Answers 2


To do that, you're going to need at least one more branch. Call it "staging," if you like. This is where you will push feature changes to, for testing. Once you're satisfied that the changes will "take," you can push them to the master branch.

Depending on how big your team is, and the level of rigor required (not all software is equal; financial and medical software require more rigorous processes), you might want to adopt a more robust model. You can study models like Gitflow to see how other teams do it:

enter image description here

But only adopt this level of complexity if your software demands it.

  • Hmm, a staging branch makes sense - we've been using our development branch for that purpose. But wouldn't we run into the same issue as before, just separated by another branch? That is, how would we guarantee that the staging branch contains only code that is safe to deploy to production, if it's a testing branch? And if we can't guarantee that, wouldn't we need to cherry-pick changes to make sure that only the ones we want to deploy get deployed?
    – ekolis
    Nov 15, 2019 at 19:40
  • One way to do that would be to merge your production branch into your staging branch, before applying your features to the staging branch. Your staging branch would then become the basis for a new release; once you've determined that all of your features are properly merged and all the tests pass, you can then merge the staging branch back into the master branch. Nov 15, 2019 at 19:43
  1. Make a new branch off of development. Might as well call it staging, like in the sibling answer.
  2. development continues as usual, of course; merge new features and whatnot to your heart’s desire
  3. Only merge critical fixes to staging (showstoppers, low-risk changes)
    • Merge changes to staging into development
  4. Let staging cook for however long it takes for you to test it
  5. Merge staging to master when it’s ready
  6. Either delete staging or let it sit around
  7. The next time you need staging: either create it (if deleted) or fast-forward it to develop

Concrete example

You have five days until some release. So you make staging, ask people to test, and make sure that incoming PRs are redirected to staging if they fix something critical to the next release.

Let it cook

The only way to test the state of the code is to slow down (only critical fixes) and test it—you won’t be able to test a code base which gets new features every day. And that means that you either have to:

  • Freeze most activity on the development branch
  • Create a new branch like staging

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.