Add daily email for 2024-04-26

Don't cherry-pick features from a branch to deploy

source/_daily_emails/2024-04-26.md

@@ -0,0 +1,31 @@
+---
+title: Don't cherry-pick features from a branch to deploy
+date: 2024-04-26
+permalink: archive/2024/04/26/don-t-cherry-pick-features-from-a-branch-to-deploy
+tags:
+    - software-development
+    - git
+cta: ~
+snippet: |
+    Don't cherry-pick features from a branch to deploy
+---
+
+I previously worked on a project where, after a code change had been reviewed and merged, it was pushed to a UAT environment for the client to test.
+
+This usually resulted in a group of changes pushed to the UAT environment, waiting for the client to test them.
+
+They would, and then decide which changes they wanted to be moved to production.
+
+Maybe changes 1, 2 and 4 would be asked to be deployed, but not 3 or 5.
+
+Someone would then cherry pick the relevant commits onto the mainline branch and deploy them to production.
+
+But, if the code isn't the same as on that UAT environment, how do you know it still works?
+
+Could a commit have been missed or could not including a non-selected commit have caused a regression or unintended side effects?
+
+`git cherry-pick` isn't a command I use often, and definitely not in this scenario.
+
+If you want to select which changes go live, feature flags are a better option as you don't need to change the commits or code you're pushing.
+
+You push all the commits from UAT to production and enable the feature flags for the things you want to release.