For our web development, we have daily to weekly deployments. There are instances where we deploy something to QA, but they don’t get around to testing it for a few days, and then we have a production fix or a new enhancement that needs to go out. Two questions:
(1) What would be a good workflow for this?
(2) What are the advantages and disadvantages to having one continuous, long lived branch called production or release, as opposed to a new release branch for each release, or just doing everything out of master and tagging it accordingly? Again, this is for web development with frequent releases that can get backed-up.
I’m not quite sure I understand your problem correctly, but my situation is similar to yours and I used (modification of) the following approach: http://nvie.com/posts/a-successful-git-branching-model/
In short, it’s about having 2 main branches (master and develop) and several types of supporting branches (feature, release and hotfix ones). Speaking about your case, you would probably deploy to QA your release branches and then when you have a production fix, you would do it in a hotfix branch and then merge it to both – master and release branches.
As for your second question… well, you know, there are so many different opinions about branching strategies out there (example…) I would say, continuous production branch works great (and it doesn’t mean you can’t have release branches to support your workflow).