git workflow 原文 以及缺点

原文链接

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.