分享我的发现、想法与心得

0%

git工作流程的记录整理

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

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

  • master 主分支,存放稳定的、随时能上线的版本。
  • develop 开发分支,所有开发的基础分支。

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

  • hotfix 修复分支,会从master分支开一个hotfix分支进行修复,修复完成后分别合并至master和develop。
  • feature 功能分支 ,当需要开发新功能时从develop分支创建,完成后合并至develop分支。
  • release 预发布分支,当develop需要提测时合并至release分支,测试完成后release合并至masster和develop。

gitflow

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

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

什么是github-flow呢?

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

github-flow

github有完整的指引

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

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