GitHub Flow

GitHub Flow – Scott Chacon - http://scottchacon.com/2011/08/31/github-flow.html

相比gitflow，github flow比较适合用在快速迭代开发的项目上。github flow可以实施与否， 我感觉很大程度上和项目是否有CI/CD以及完善程度有关系。不过理论上，所有快速迭代开发的 互联网项目，都需要有相对完善的CI/CD系统来支持。相比gitflow, 我总结下有这么几点差异：

1. 开发分支都是从master而不是dev开出来
2. master必须始终是deployable的
3. 线上部署使用master分支而不是release分支
4. feature和hotfix分支没有本质差别

So, what is GitHub Flow?

• Anything in the master branch is deployable
• To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
• Commit to that branch locally and regularly push your work to the same named branch on the server
• When you need feedback or help, or you think the branch is ready for merging, open a pull request
• After someone else has reviewed and signed off on the feature, you can merge it into master
• Once it is merged and pushed to ‘master’, you can and should deploy immediately

gitflow最大的问题在于它太复杂了，当然它功能也很强大，可以用于各种软件项目。 但是gitflow更加适合开发周期很长的项目，而github flow更加适合需要快速持续迭代的项目。

One of the bigger issues for me is that it’s more complicated than I think most developers and development teams actually require. It’s complicated enough that a big helper script was developed to help enforce the flow. Though this is cool, the issue is that it cannot be enforced in a Git GUI, only on the command line, so the only people who have to learn the complex workflow really well, because they have to do all the steps manually, are the same people who aren’t comfortable with the system enough to use it from the command line. This can be a huge problem.

For teams that have to do formal releases on a longer term interval (a few weeks to a few months between releases), and be able to do hot-fixes and maintenance branches and other things that arise from shipping so infrequently, git-flow makes sense and I would highly advocate it’s use.

For teams that have set up a culture of shipping, who push to production every day, who are constantly testing and deploying, I would advocate picking something simpler like GitHub Flow.