Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

选择适合自己的 git 工作流

  网络上曾经流传过一篇「A successful Git branching model」,还被翻译成各国语言转得火热。虽然这个方案本身并没有什么槽点,但很多团队盲目地选择了所谓「成功」的方案,完全没有考虑自身项目的实际情况。「成功」是不可复制的,学习应该是学习思想而不是方案。
  我觉得对于大多数项目而言,那套 git 工作流太繁杂了。

版本问题

  那些被编译成二进制后安装到用户的设备上的应用确实有版本的概念,而且版本是它们的必要概念。但 Web 呢?用户不需要下载安装什么,通过浏览器访问的,版本就是一个可有可无的概念。一些管理上比较严谨的团队确实会给 Web 项目加版本,但也有一些团队觉得 Web 项目的版本并没卵用,直接取消版本的概念。

发布频率

  即使是一个需要考虑版本的团队也应该先看看自己项目的发布频率有多高。App 发布需要用户下载安装,甚至可能还需要 App Store 审核,它们的发布周期普遍较长。如果是一周一发布,那确实可以采用一些流程化的工作流。但我主要还是说 Web!Web 项目是实时发布实时生效的,只有一些市场稳定的项目才能做到如此慢节奏的开发。遍地都是竞争对手的项目如果照这样的工作流开发,公司还要不要活了?很多团队都是每天发布,甚至有些比较激进的团队会一天发布多次。这么高的发布频率,开个 master、develop、release 分支互相整合完全是在浪费时间。

并行开发人数

  如果一个项目经常出现同时有 5 个以上的开发者,那确实需要非常严格的工作流。但如果总是只有两三个开发者在并行开发,繁杂的工作流带来的弊就大于利了。或者一个更极端的例子就是谁会对自己玩的开源项目搞这么一套繁杂的工作流呢?

没有最好,只有最适合

  我不是来推广什么「成功」工作流的,因为我觉得这就和项目架构一样很难设计出一套通用的东西。或者即使有通用的,那它一定只是万金油,只能用来止止痒而已。

网名:
54.226.58.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^