Cherry picking commits is an anti-pattern
git cherry-pick is a command that allows you to re-apply changes from existing commits - typically moving commits from one branch to another. Whilst it's good for some use-cases, I believe that it's generally an anti-pattern.
As I mostly do trunk-based development so only have a single branch, it's not a command that I'd run often - but I have seen it used in a Git Flow-type scenario where there are multiple long-lived branches and various other short-lived ones. Commits can be cherry-picked between a long-term branch like develop onto a feature branch rather than merging or rebasing, or to re-apply a hotfix from the main branch.
The main issue that I've seen with cherry-pick is where a number of changes have been merged into a branch which is being used for user acceptance testing by a client or product owner. They decide to approve some of the changes but not all, and the approved commits are cherry-picked onto a production branch and deployed.
In my opinion, this is very risky as there's no guarantee that the cherry-picked changes will work without the others, and as the artifact that's pushed to production is different to what was tested against, it arguably affects the value of doing the testing at all. Ideally, once the release has been tested and approved, the same artifact will be deployed - ensuring consistency and reducing the risk of any errors.
Potentially, the cherry-picked changes could be moved onto a release branch and tested again together without the other changes, but this would increase the testing overhead and the time for the changes to release production.
A good automated test suite would help, ensuring that the tests still pass once the cherry picking is done.
In this situation, I'd rather use feature flags (also known as "feature toggles"). This would mean that the code between the two environments would be the same, and allow for functionality to be enabled or disabled as needed. If a feature wasn't selected to be released, then it's feature flag would be disabled until it's approved.
A feature flag would also allow a feature to be switched off if it was causing errors without the need for a code deployment. If a change did need a code change, if you're following continuous integration and delivery, it would be easy to apply and push a fix.
These are the use-cases that I can think of or have seen for git cherry-pick. If you know of any others or use cherry-pick in your workflow in another way, reply to the email and let me know.
- Oliver
P.S. Do you want to learn about automated testing in Drupal? Take my free 10-day email course and get daily lessons straight to your inbox.
