git工作流程的记录整理

git flow 普片认为最早是由荷兰独立软件工程师 Vincent Driessen 在2010年发表的 一个成功的Git分支模型(A successful Git branching model) 这篇文章提出的。文章中提到文森特早在一些项目中使用git flow，并证明它是成功的。文中提及使用git flow的根据分支策略解决自动构建和部署问题。文森特后来制作了 nvie/gitflow 工具用于扩展git实现git flow功能，gitflow思想也推广了出去。

仓库在一般的情况下存在 master 和 develop 两个主要分支。

master
develop

根据项目的需要可能添加下面这些分支：

hotfix
feature
release

每个分支都有其职责，为团队中的开发人员缓解功能跟踪、预构建及快速修复等问题。在一些场景下gitflow会显得很臃肿，在一些快速迭代的产品中会使你必须在 master , develop , release 三条分支中频频切换来完成合并维护，写将会花费你大量的时间和精力。

对于giflow的过于繁琐和复杂， Scott Chacon 提出gitflow的问题和 github-flow 的思想。

什么是github-flow呢？

• 首先master分支中的任何内容都是可部署的
• 创建一个来自master的具有描述性的分支（如：new-oauth2-scopes）
• 在本地提交该分支，并定期将您的工作推送到服务器上的同名分支
• 当您需要反馈或帮助时，或者您认为分支已准备好进行合并时，请打开拉取请求（PR）
• 在其他人审阅并签署该功能后，您可以将其合并到master中
• 一旦合并并推送到“master”，您就可以并且应该立即部署

在 github 有完整的指引

新分支只专注单个功能进行开发，使开发者更专注于编码而已不是管理这些状态。github-flow中增加了合并请求(PR)和检查代码(review)部分更是为项目提供了很好的保护，在这步能很好的控制编码风格和编码错误等问题，检查和审核他人的代码不但让组内成员相互学习提高项目参与感。同时也为团队降低了人员流失所带来的风险。合并前的部署环节为分支代码提前在生产环境测试，这将会是上线前的最终测试，通过测试后将合并至主分支发布上线。

能看出github-flow比gitflow少了预发布、修复、增加功能、开发的分支，工作流程简单了许多。但是预发布、修复、增加功能、开发等概念在整个软件开发过程中任然是存在的，其他环节无需在编码环节上体现出来。github-flow只专注编码，其作为在软件开发的编码阶段是具有非常高的参考价值。