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).