There's a flaw in my thinking about Git that I can't sort out. It's probably rooted in an ineffective workflow.
Here's what I'm trying to do with Git.
When I want to push to production, I create a release of master, say version 1.2 and version 1.2.1, etc.
But when I'm implementing code changes between pushes to prod, I do this.
Each change is a branch that maps to a ticket describing the bug or features.
So pretend I have three changes: CHANGE1, CHANGE2, BUG1
I create a CHANGE1 branch of master. When I'm done with the change, I merge to master and the CHANGE1 branch is essentially useless and can be deleted.
I do the same with CHANGE2 and BUG1, but I haven't made a release because a business owner needs to review that the changes solve the problem outlined in the ticket.
So if all look good except CHANGE2, how do I make a release of master that doesn't include CHANGE2 changes?
One way I solve this is that I don't merge to master and when the person is verifying each ticket, I switch the git branch so they're running that code change. This always me to merge what passes into master and create a release. The limitation is that if more than once change needs to tested at the same time because of dependencies, I guess I could create another branch of master that I merge the two branches into?
What's the best approach to this? I'm open to suggestions not outlined here. I feel like I'm missing something that makes this process beautiful. It seems clunky either way I do it.
i would merge separately to a review branch if the feedback is ok i merge to master if CHANGE2 NOT OK i remove it from review and merge to master