Are there Git workflows for rolling release web applications?

Question

My team of about a dozen developers produces a web application in a rolling release model: Once some featureset is ready, it's reviewed by a senior developer and pushed into the QA system, then into the production system. This usually happens several times per workday.

The VCS currently in use is SVN, and pushes to the QA and production system are done with a weird in-house deployment tool which works on the SVN, but file-based (so if you need to push a new version of file X, and X has unpushed changes from some other changeset that you don't want to push yet, you have a problem).

I plan to evangelize for switching to Git, so I'm thinking above how a workflow could look like. The usual suggestions like the often-linked Successful Git branching model don't apply since we don't have versioned releases.

Question 1: Are there any documented workflows I could look at for further inspiration, similar to the one linked above, which are optimized for rolling releases? Or would you suggest one?

I have tried to model a workflow on paper, which uses feature branches and master as usual, and has further branches which mirror the state of the QA and production servers. (One would only merge in there from master.)

The problem I'm not able to overcome is when something in master is not release-ready for some reason. For example, let's say the feature branch foo is considered done, merged into master and pushed into the qa branch. Then the same happens for the feature branch bar. Now on the QA system, we discover that foo is broken and needs more development, while bar is ready to be pushed into the production system. But there is no commit on master which includes bar, but not foo, so what shall we push? The only thing that comes to mind is to revert the merge commit for foo into master. (Behind the link, Linus explains several problems with reverting merge commits.)

Question 2: Any idea how to overcome this problem more elegantly?

Answer 1

Here is the workflow I have used with great success so far:

---

• Each developer works on their features/fixes

• Once they're satisfied with the work, they push the branch to remote

  git push -u origin newfeature

• The QA or test [server | person | team] pulls master and the feature branch you want to release, and merges it into master but does not push to remote

• Once the feature is QA'ed it gets merged with --no-ff and pushed to master

• The feature branch can now be deleted

  git push origin :newfeature

• The live server always pulls from master

---

For us this ensures that live server contains a rolling release of the current "best" code.

If you are interested in a branching model I have found this to be quite useful: nvie.com/posts/a-successful-git-branching-model/