Cleaning Up Your Staging Branch

It comes a time in lifetime of every long running project for some spring cleaning. It usually means removing dead code, fields in database tables or even whole tables. In this post, we’re going to focus on cleaning up the branch in our git repository, our beloved staging branch.

Just to clarify, a staging branch is a branch where all feature branches get to be merged to both show the progress to the client and test if multiple features play well together. Resolving conflicts in this stage is much more easier on your nerves than finding about them just after you ran git merge feature-branch on a master branch.

This is an example of one such staging branch after some time of development (list of feature branches):

  • add-newsletter-subscribing
  • remove-order-notifications
  • fix-slow-query
  • enable-multiple-product-images
  • add-mobile-payment-method
  • ...

All is fine and good, but some of those feature branches will never make to the master because feature got cancelled, or whatever else reason. These branches pollute our staging branch and actually might cause bugs, wrong code behaviour or inability to test a feature.

To remedy this, let’s clean  up the staging branch by recreating it. But first, let’s see what branches are merged into staging branch that are not yet available in the master branch. To see that, list all branches merged both in master and staging branches:

[prism key=”git-branch-merged” language=”bash”]

The -a flag will show both local and remote branches

Ok. We now have 2 files: merged-master and merged-staging. If we diff them, the difference will show us what branches are not merged in master. One such diff might look like this:

[prism key=”git-branch-diff” language=”bash”]

The -y flag will output diff side by side. To suppress common lines, well, use --suppress-common-lines

We can now proceed with creating a new staging branch which will become our clean staging branch. After we merge only branches that really need to be in the staging branch, we can run tests on new staging branch (you do have tests, don’t you?) and if everything works, we can push that new branch to staging:

[prism key=”git-recreate-staging” language=”bash”]

Time to test everything. Run your testing suite or do some manual testing if you want, and when you’re ready let’s force push this bad boy back to origin:

[prism key=”git-push-staging” language=”bash”]

And this is it. Your new staging branch is clean, fresh and has only branches that are actual and will be pushed live.

Leave a Reply

Your email address will not be published. Required fields are marked *