Sometimes, it's necessary to deploy a set of features and/or bug fixes to production before part of the current "testing" branch has been tested completely in a Q/A or staging environment.
In Git, there are many approaches to managing this problem, such as maintaining separate feature environments where branches can be tested before they're merged to a central "integration" branch, or temporarily reverting a changes on the "testing" branch so a normal release can be performed. This blog post explores another, simpler alternative.
Git flow
Our particular client project is already using Git flow, a long-standing and successful Git branching workflow. Unlike some projects that may opt for continuous delivery with a model like GitHub flow, the nature of this project still merits regular releases, and git flow works well for this use case.
Squash and merge
The approach works best if you already merging pull requests using the squash and merge option in GitHub, or Bitbucket, or GitLab. Without this, picking out the right commits is harder. Plus, enforcing this merge type in your repository helps clean up the Git commit history in the long run.
Hotfix branches
While typically a hotfix branch is used to push out a single change that is immediately necessary on production, we found they also work well for deploying a collection of commits from the "testing" branch (develop in git flow) to production. If you're already squashing commits, the workflow is straightforward.
-
First, start a hotfix branch:
sh git flow hotfix start my_release -
Then, cherry-pick the commits that you want from the
developbranch to the hotfix branch:sh git cherry-pick b0c5d79e1961...sh git cherry-pick 025867aa02a5f... -
Finally, finish the hotfix:
sh git flow hotfix finish my_release
This workflow will apply only the commits you need to the production branch, and it gives you an opportunity to combine (and run unit tests on) the various commits before merging to the production branch. When the hotfix branch is also merged back to the testing branch, it should apply cleanly assuming the affected code has not been since changed on the testing branch.
Caveats and conclusion
A few caveats exist with selectively deploying code to production:
- Commits that include schema migrations should be avoided, unless you're positive the migrations will remain in the appropriate order on the production branch.
- Since the hotfix branch may not have been deployed to its own environment before production, the chosen selection of commits may have had limited testing.
In short, this approach works best for a collection of bug fixes and small code-only changes, rather than large features with schema migrations. For the latter, it's best to complete the necessary testing and schedule a production release once the code is ready, or go through the more challenging process of rolling back the code (and migrations) from the test environment before cutting a release.
I hope this helps with the git branching workflow on your project! Please feel free to leave any comments or questions below.