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:
The general principles:
- Every branch starts at
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.
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.
- 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).