Git workflow 选型分析

原创 2016年08月31日 14:55:33

前言

「A successful Git branching model」 这篇文章,应该是我第一次真正开始从 workflow 的层次来思考和看待 git 的使用问题。

而实际根据文章中提到的 「gitflow」 来进行实际项目代码演进的时候,发现无法完全契合我们的实际需要。综合陆续对 git 的各种主流 workflow 的了解。提炼出一点:没有万能的 workflow,只有最适合的 workflow。

而这篇文章,就是来讨论一下如何挑选、使用、优化项目的 git workflow。

原则

在对 git workflow 进行调研的过程中,「Git Workflows That Work」这篇文章让我产生了一些启发。特别是其中他提到的选择 workflow 的 guildelines ,我认为可以作为我们针对自己身实际需求进行 git workflow 设计的准则。特此引用并翻译如下:

  • Branches should be used to represent a single deliverable request from the business- like a single user story or bug fix. Something that can be approved by the business that contains everything needed for that single request to be released- and nothing more!

    「Branch 仅用于唯一且独立的需求。」

    每一个分支必须单独代表一个来自需求侧的可发布内容,比如一个 userstory 或者 缺陷修复。这个来自需求侧的可发布内容内容,包含了且只能包含所有这次发布所需要的东西。

    这条强调了 branch 的独立性、完整性,以及 branch 的开发目标的唯一性。

  • The longer a feature branch lives without getting merged in for a release, the greater risk for merge conflicts and challenges for deployment. Short lived branches merge and deploy cleaner.

    「一个分支 merge 到 release 时间越早越好。」

    一个功能分支过于长时间的独立维护,而不合并到 release 分支中,会对开发者带来极大的风险和挑战。开发周期短的分支,会有更简洁清晰的合并以及发布。

    这里提到的风险,意味着合并冲突出现概率、以及回归测试范围。

  • Business owner involvement in your workflow is essential. Don’t merge, don’t deploy, don’t work without their input. Otherwise pain and tears will ensue (or worse).

    「万物由需求而生」

    Business owner 必须要参与到你的 workflow 中来,不要在没有需求的时候做合并,发布和其他工作。不然接踵而至的必然是血和泪。

    这段描述的有点奇怪,但是可以理解为不要做没用处的事情,开发过程一定是由需求来指导的,所以没有需要,不要动代码。比如说你的分支都是以需求名称命名,或者发布版本命名,而merge,必然代表着这些需求或者版本的完成和上线。

  • Avoid reverts. Test, test, test your branch before a merge. When merging use git merge –no-ff, which will ease merge reverts if really needed.

    「避免 revert 。」

    避免 revert 。在 merge 之前,记得在你的分支上测试!测试!测试。不过使用 git merge --no-ff 命令来完成 merge 操作,将会让你在实在需要进行 revert 操作的时候更简单。

    关于git merge --no-ff 命令,看这里

  • Your workflow should fit how you release. Do you release continually, multiple times a day? Do you have 2 week sprints with completed work to release on a regular schedule? Do you have a business Change Control Board where all released items must get reviewed and approved first? Does someone else run your releases, like the Operations team or a Release manager? Your branching and merging strategy needs to make releasing easier.

    「根据发布流程选择 workflow」

    你的 workflow 需要适合你的发布方式。考虑你是否每天都会多次、持续的进行集成发布?你是否采用了2周的 sprints 周期来完成你的需求,并统一发布?你是否有一个需求管理面板,并且要求所有的发布内容必须经过管理面板上的 review 和 批准?你的发布类容是否被其他人引用,比如配置管理团队或者发布管理团队?你的分支拉取和合并策略必须使你的发布工作更加容易,而不是更难。

    同样的,对于产品的发布环境,是否有完善的 testcase ,充分自动化的测试平台和工具,以及明确的验收标准。决定了发布的成本。在发布成本较高的时候,不要因为你的workflow ,导致平白多出不需要的发布次数。

  • Complicated workflows drive people crazy. Make it simple. Review your workflow and ask how you can simplify it. In actively making things more simple, you will also make them easier to understand and work with as well as easier for others to adopt and maintain.

    「越简单越好」

    复杂的 workflow 会让每个人抓狂。经常回顾和总结现有的 workflow ,找到让它更简单的方法。实际上,workflow 越简单,越容易被大家理解,从而长期保持下去。

    举个简单的例子,release 分支完成了测试,为什么非要 merge 到 master 分支上再 deploy 。如果没有为什么,是否可以直接在 deploy 分支上发布?

正确选择 workflow

如何正确选择 workflow 是我目前也在研究的内容,暂时还没有类似于 「选择 workflow 的黄金法则」之类的结论出来。不过可以先看看我们能了解到的不同 workflow 对应于不同情况的优缺点分析。

github workflow

github workflow

github 大家都用过,他的这个工作流程典型特征是大家都直接从 master 分支拉取一个 feature 分支,开发完了以后,直接merge回 master 分支。这个比在「A successful Git branching model」 中提到的流程要简单太多。

使用这个模式的问题,就是如何保证 master 分支上的内容的可发布性和可测试性。由于没有专门的 develop 分支进行功能分支合并,没有专门的 release 分支进行测试验收,所以 master 分支上很容易出现无法发布的临时产物。

所以当使用这个 workflow 的时候,团队必然需要具备这样的条件:

  1. 各个feature 之间的修改内容的高度不相关性。这样合并的时候才能有较低的冲突概率。
  2. 高覆盖率的测试工具,这样能在 feature 分支合并之前完成功能验收,保证合并之后的缺陷率。
  3. 高效的测试回归流程,这里可以通过持续集成工具上部署高自动化测试流程将merge 操作和回归测试自动化的完成,从而保证每次merge 操作都能快速的完成回归测试。保证 master 分支上的可用性。

在这种模式的启发下,可以考虑使用 rebase 命令来代替 merge 命令,从而时你的 git 记录就像 master only workflow 一样干净整洁。

你可能会记得:永远不要用 rebase 这个建议。但是只要你理解 rebase 的含义,也是可以用的。关于 rebase ,我觉得这篇文章写的挺好的。

Skullcandy’s workflow

这里不深入探讨 skullcandy 这家公司是具体做什么的了,简单看一下这个 workflow 也是一个比较有代表性的模型。

在这种 workflow 中,通过 QA branch 这个分支,一定程度降低了在 github workflow 中,对验证、测试回归的工具和工作流的要求,在这个分之中,将开发人员和测试等其他验收人员的职责通过 branch 做了划分,从而测试人员只需要在 QA branch 上做验收测试,并且由于 QA branch 分支的合并节奏是可以控制的,所以可以根据发布周期来控制 QA branch 分支上的合并时机。

这种 workflow 应该说比较适合敏捷开发过程中固定周期的发布行为。通过固定的敏捷周期来约定 QA branch 的同步时间。

这种 workflow 的坏处,由于无法第一时间快速的 将 freature branche 上的内容进行合并,验收。这样会带来后续更高的代码冲突概率和更迟的缺陷修复时间。

master only workflow

这个workflow 比 github workflow 更进一步。但是对测试、发布的要求奇高。

过去我竟在个人独立项目中使用这样的 workflow 进行开发,自然这种情况下我是不需要回归测试、发布等流程的。

另外 stackworkflow 上的这个答案中提到的建议,也说明了使用分支的优势。

版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

动态透明加解密技术分析与产品选型

一、常见防泄密技术方法简介:     随着企业信息化应用的深入,企业员工大部分工作都在计算机上完成,各类报告、报表、设计图纸等重要成果都以电子文件的形式存在,而电子文档很容易通过邮件、移动存储设...

根据企业信息化应用需求来分析工作流平台的选型

工作流选型的参考

三款典型的APM产品选型分析

本人对现阶段应用监控产品做了调研, 主要围绕Pinpoint,Aliapm,Cat这些产品,虽然都是监控产品但是挑选的是有典型性、侧重点不同的应用监控系统,一共分三款产品进行介绍 1...

NoSql对比与选型,应用场景分析

传统“关系型数据库”在应付互联网WEB2.0应用已显示的力不从心,由其是超大规模和高并发的SNS类型的WEB2.0网站。 主要需要应对以下三方面难题: 1、对数据库高并发读写的要求。 2、对数据...

消息队列中间件的技术选型分析

消息中间件是一种由消息传送机制或消息队列模式组成的中间件技术,利用高效可靠的消息传递机制进行平台无关的数据交流,并基于数据通信来进行分布式系统的集成。目前业界有很多的MQ产品,像RabbitMQ、Ac...

消息队列中间件的技术选型分析

消息中间件是一种由消息传送机制或消息队列模式组成的中间件技术,利用高效可靠的消息传递机制进行平台无关的数据交流,并基于数据通信来进行分布式系统的集成。目前业界有很多的MQ产品,像RabbitMQ、Ac...

消息队列中间件的技术选型分析

消息中间件是一种由消息传送机制或消息队列模式组成的中间件技术,利用高效可靠的消息传递机制进行平台无关的数据交流,并基于数据通信来进行分布式系统的集成。目前业界有很多的MQ产品,像RabbitMQ、Ac...

Git Workflow

前提条件:Git + GitHub/GitLab 根据task创建对应的develop branch 当我们接到一个新的task,首先第一步要做的就是创建一个新的开发分支(develop branch...

Git Workflow最佳实践

Git Flow最佳实践

Patch workflow with mutt and git

Patch workflow with mutt and git It's easy to grab a patch from a mailing list with mutt and get it...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)