I have "main" and "release" branches.
People actively commit to "main" and once a month we make a new release. Not everything in main should go into the release branch, but we must pick and choose individual commits.
Let's say that in main we have commits A, B, C, D, E. In release we have less commits, of course, because development has gone further since the last release: A, B, C
I'm using "github compare" to check the differences. I use the git log entries to decide what should go into release and write release notes accordingly. In this case, if I compare master->release, I get commits D and E, which is what I need.
The problem is: let's suppose I want to release E, but need to hold off D for the time being. How do I do that?
So far we've been using cherry-picks, but it's not great. The problem is that the history I get on release, in this example, is A, B, C, E' (where E' is the cherry-pick of E, marked with a quote because it's effectively a different hash). Next time I want to compare master with release I get problems. Let's say, for example, that main has gone further and is now A, B, C, D, E, F. If I compare, github will show that the missing commits from master into release are: D, E, F. Which, technically, is correct, because E and E' are different hashes, but I know they're the same code, and I would really like to only see D and F.
I read quite a bit on the subject. In particular, I liked this: Stop cherry-picking, start merging, and maybe we should stop using cherry-picks the way we're doing (even though our use of cherry picks is limited to cutting releases, so the chance of triggering bombs on someone else's lap is probably negligible).
Still, I haven't found a simple solution that doesn't involve stuff like adding some kind of meta-data to commits, or writing a custom offline tool.
Does anyone have a piece of wisdom to share? I can't believe we're the only ones having this problem, I'm sure there's a smarter way to do this.