原文链接
http://nvie.com/posts/a-successful-git-branching-model/
有人发现git work flow的缺点，历史提交会变得混乱
http://endoflineblog.com/gitflow-considered-harmful
http://endoflineblog.com/follow-up-to-gitflow-considered-harmful
http://endoflineblog.com/oneflow-a-git-branching-model-and-workflow
在合并的时候，优先使用rebase
范本，使用rebase + (merge --no --ff)
https://github.com/tart/tartJS
$ git remote -v
origin https://github.com/tart/tartJS.git (fetch)
origin https://github.com/tart/tartJS.git (push)
What are the pros and cons of git-flow vs github-flow? [closed]
There is no silver bullet workflow where everyone should follow, since all models are sub-optimal. Having said that, you can select the suitable model for your software based on below points;
Multiple versions in production - use Git-flow
If your code is having multiple versions in production (i.e. typical software products like Operating Systems, Office Packages, Custom applications, etc) you may use git-flow. Main reason is that you need to continuously support previous versions in production while developing the next version.
Single version in production simple software - use Github-flow
If your code is having only one version in production at all times (i.e. web sites, web services, etc) you may use github-flow. Main reason is that you don't need to complex things for the developer. Once developer finish a feature or finish a bugfix its immediately promoted to production version.
Single Version in production but very complex software - use Gitlab-flow
Large software like Facebook and Gmail, you may need to introduce deployment branches between your branch and master branch where CI/CD > tools could run, before it gets in to production. Idea is to introduce more protection to production version since its used by millions of people.