Merging Git Database Commits from One Branch to Another without Cherrypicking

We have main two Git branches at our company:
During our Sprint,

Everyone has (local branches)

Release branch: Contains prepared/developed code, ready for testing, and

Master branch: Production- final ready code

I read in Git, Cherry picking is bad.

https://blogs.msdn.microsoft.com/oldnewthing/20180312-00/?p=98215
http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html

After items are placed in master, they are ready to be deployed.
Sometimes , we do not move all Release items into Master, many reasons:, delay schedule, conduct more testing, late issues. What is the proper Git Devops strategy to only move certain items into Master? Should we backout commits, so we can do a clean merge?

Databases are different, as we are conducting change scripts, and not overwriting binaries like applications, etc.

Example:

Release branch ------- -------------> Master

Commit A, B, C, D, E -------------> Commit B,D

I read in Git, Cherry picking is bad.

Be careful of such blanket statements. They take on a life of their one, and after a while you have a lot of myths in your team (or workplace) about no cherry-picking, no re-basing, no xyz. These are all just tools; there are times to use them, and times to not use them. Nothing is generally bad.


Sometimes , we do not move all Release items into Master, many reasons:, delay schedule, conduct more testing, late issues. What is the proper Git Devops strategy to only move certain items into Master?

Adam Dymitruk's Branch per Feature works splendidly for that. In short:

There are these branches:

• 1 master branch

• 1 qa branch

• n feature-123 branches

The general principles:

• Every branch starts at master.

• Only feature-123 branches receive regular commits.

• qa is created by starting fresh from master, and then merging any feature-123 branches that should be in testing. Whenever qa needs to be changed, it is created fresh again, there are no other commits into it. This happens very frequently.

• When qa has been released/deployed, it is simply renamed to master and replaces the previous one. At this point, all remaining feature-123 branches are rebased onto the new master. The git rerere cache is used to avoid having to do repeated conflict resolution.

This scheme works great if you have developers who can stomach the rebases. You frequently find people who think they are bad, or who simply do not allow it - then you're out of look obviously. But if you get it to run in your team, it is very smooth, and ultra flexible. You literally never ever need to "back a commit out" or do cherry-picking to revert a commit, or whatever.

Read Adam's page, it explains this in more detail, but basically that's about it. You'll need to create your own tooling for the individual steps (for example, to pull the feature branches which are supposed to go into qa from your Jira instead of manually doing that), but that's not too hard.

Addendum:

• Trivially, you can have more than one qa-type branch at any point in time. For example, you will likely start with one that always has all features which are deemed close to "done" (but which may not have successfully passed test yet); and maybe another one (let's call it rc - release candidate) which contains a subset of that for the very next release.

• Adam also describes a ci branch; it is nice, but optional (we don't use it at all, and are not missing it).

StackExchange DevOps Q#4482, answer score: 2