Most Git workflows do not address picking what is released. Once a feature branch has been merged back to 'development', it is in the release pipe, pending QA and Business validation.  Once in 'development', code/branches cannot easily or arbitrarily be plucked out to go directly to production as the code is often intermingled with other branches.  But the code changes in 'development' can be manually re-coded (Git patches help) into a hotfix branch from 'master'/'production' with the risk of not being QA-ed.

The 'Git single branch strategy' primarily removes the pain point of the conflicts between 'master' and 'development', while providing a clearer history of production releases, and an easier rollback with switching branches.

Generally picking what to release is largely mitigated by how, and the order in which Tickets are chosen. However, the release pipe can be slowed down by a Ticket/branch needing time to fix, or be validated by QA or Business.  To remove the blocking branch, depending on the changes, the feature could be hidden, or removed if a small change, or more likely wait for the fix(es) and QA.

Hopefully the upfront choosing of Tickets and quality of specifications somewhat mitigates the blockers.

Some Git strategies to mitigate blockers in the release pipe, which are caused by Tickets that often require feedback once seen.

1) Put less in the release pipe: (Less is more)

If limit releases to one branch per release, then there is no re-picking once in 'development'.  Basically the other feature branches would queue up waiting to be picked and for merge to 'development' and QA-ed.  Which leads to the pros and cons of Staging branches.

2) Staging branches:

Another process to maybe help with picking branches for release is to not merge feature branches back to 'development' until picked.  The feature branches could be deployed to their own directory (devsite.com/branch/123-shortdesc) be QA-ed, reviewed by Business, then if ok, merged to 'development'.  Then when decided to go to production, everything currently in 'development' is QA-ed again, fixes added via branch updates or a new branch, and then released via 'master'/'production'.  

Note, if after being merged to 'development', production release decisions change, well, then we are back to the same problem of doing hotfixes, or hiding not ready functionality, or waiting for the fixes.

Also this approach can be a burden on the developers: fixes enhancements, code cleanups, won't be seen or utilized until the branch is picked, and those fixes/enhancements might be required or desired for another branch, thus duplication of code which probably means conflicts later.  Before merging the feature branch to 'development', 'development' would need to be merged back to the feature branch to handle any changes or conflicts in the branch, so the developer can test again before merging to 'development'.  And as the code won't be fresh on the developers mind, there is a higher risk of mistakes to be made during the merge to 'development'.

pros: 

• able to preview branches before release
• able to choose branches for release

cons:

• more work for Business and/or QA as the merged branches in ‘development’ still need to  be reviewed
• if decisions change to remove a branch or hotfix a branch to production before qa, same problems
• more burden on developers, potential conflicts, developing the branch twice: once orig, then later (days, weeks) when picked
• dev-ops + some app work to make 'their own directory' happen

Committing often, merging often seems to be better for code quality.

3) Feedback branches, Preview branches: (A hybrid of Staging branches)

For branches which require Business or early QA feedback, after development is done, but before QA or merging to 'development', push the branch to a preview location (devsite.com/branch/123-shortdesc).  There it can be previewed for one or two days, before being merged to 'development' and moved to QA; required feedback branches should not be held for a long time, else the cons of Staged branches may become apparent.  The branches that require feedback should be marked as such before development.  Every branch should not be marked as requires feedback, only a few should be.

pros: 

• able to preview branches marked as feedback before release
• should reduce fixes needed when in 'development' for QA
• as only a day or two delay, no large time incurred burden on developers

cons:

• does not allow changing order of released branches
• more work for Business and/or QA as the merged branches in ‘development’ still need to  be reviewed
• if decisions change to remove a branch or hotfix a branch to production before QA, same problems
• dev-ops work  + some app work to make 'preview location' happen

Hopefully some useful Git strategies when dealing with Tickets that often require feedback once seen.

-End of Document-
Thanks for reading