Git branching models review

Good explanation for well known branching models : https://www.atlassian.com/git/workflows
git-flow: http://nvie.com/posts/a-successful-git-branching-model/
git-flow script: https://github.com/nvie/gitflow
interesting explanation of git-flow: http://danielkummer.github.io/git-flow-cheatsheet/

jgit-flow: https://bitbucket.org/atlassian/maven-jgitflow-plugin/wiki/Home
http://blogs.atlassian.com/2013/04/git-flow-comes-to-java/
http://blogs.atlassian.com/2013/05/maven-git-flow-plugin-for-better-releases/


just another workflow (Dymitruk Model): http://dymitruk.com/blog/2012/02/05/branch-per-feature/

another overusage of git (but helps its owners): http://stackoverflow.com/questions/19695127/git-workflow-review


One man have the same problem as we (Feature branch vs Jenkins): http://www.giorgenes.com/2012/04/some-thoughts-on-continuous-integration.html


So here is summary:
- git workflow is never ideal and never suit all needs;
- git workflow is reflection of release approaches and language nature and nuances of current project (
 a) existence of CI and level of CI fanaticism (to automate all or have special person that manage CI),
 b) QA/UAT staging environment and how that team approve release to be applied to production,
 c) special engineer that will focus on releases,
 d) versions bump approach,
 e) project structure and building nuances (maven, ant, gradle, scripts or compiled language),
 f) frequency of releases and hotfixes,
 g) requirement of previous versions support or back-porting policy,

 h) project manager that can always apply pull requests, or any code review system (gerrit)
 ....
).
- every "enterprise-successful" workflows create some script/plugin to follow its model with hiding all git commands, and ease git management.
- if you do not like over-engineering, so stay with simplest branching model (all in master, feature branches goes base on master)