I've been thinking about this for a while, so when James Cowie Tweeted the question I took the opportunity to respond.
What does your git/scm workflow look like with continues deployment? Questioning my git flow esq due to roles of the branches. #lazyweb
— jcowie (@jcowie) December 27, 2015- Designate a master branch.
- Align pull requests to features.
- Merge only test-passing pull requests.
- Cryptographically sign test-passing tags.
- Build signed release packages.
Pretty straightforward, this. It may be easiest if master is just master.
Don't overspecify feature branches. Instead, allow developers to create and destroy branches at will. (Personally, I think devs should have their own remotes.) Devs should not push to shared branches. If two devs need to work on the same feature, make one responsible for the main pull request, and the other can make a pull request against the first.
Build and test every pull request (even the secondary ones). Prevent merging any pull request that fails tests. Prevent merging any pull request that reduces coverage (but allow for annotations that skip coverage for code where testing doesn't make sense.) This means that new, uncovered code will not be mergeable.
Every push to master should be done with the intention that its HEAD (at that time) is deployable, but merging a pull request should not be done automatically. Since you don't merge entirely automatically, you have an opportunity to embed a few important manual quality assurance and information security steps at the merge point. This is a good opportunity to designate and sign the tag that the new release will have. (Continuous deployment is all well and good, but show me how to autodetect the difference between a patch and a minor change so you can follow Semantic Versioning.)
Signing tags is good, but if every developer on a project commits to it, you can sign every commit. That's better. If you want to understand the difference, read this other post.
Finally, have an actual build process, even if your product just deploys to a web server somewhere. That build process could create a binary, a Docker image, or just a tarball. The important thing is that the artifact is a cryptographically signed snapshot independent of your git history. Ops, customers, auditors and information security specialists should be confident in your release independent of their knowledge of git internals.
project commits to it, you can sign every commit. That's better.