[译]Git回滚合并2015-05-26

如果工作流严重依赖分支合并的话,也难免会碰到需要回滚合并的情况。而且回滚还分为两种情况:永久回滚,或者回滚后在稍后重新合并。

假设有如下分支图:

分支图

注:Git分支图中的箭头表示依赖关系,并不是分支发展路线。发展路线和箭头是相反的。也就是图中是从C1开始一直发展到C12的。

假设要回滚C10。

第一种解决方案是将master回退到C8,然后将两个特性分支jk/post-checkoutdb/push-cleanup合并过来。

git checkout master
git reset --hard [sha_of_C8]
git merge jk/post-checkout
git merge db/push-cleanup

完成之后,分支图如下:

分支图

接下来就可以继续在新的master上工作,然后在适当的时候将tv/rebase-stat合并回来。

团队使用Git和Git-Flow手记2015-05-11

去年10月份,在我们被产品节奏逼到墙角无路可走的时候,我们在几乎没有准备的情况下,在团队中引入了Git。目前时间已经过去半年,回顾这半年的时间,基本还是运作得比较顺利。当然过程中也少不了踩坑,因此记录一些心得。

Why Git?

如果用一句话来说的话,我们是冲“分支”而来的。背景如下:

团队的固定版本节奏为两周一个版本,一周半的时间开发,半周时间测试发布。如果使用软件工程中的概念来说的话,这是一个比较典型的瀑布式流程,即“需求->设计->开发->测试->发布”,然后周而复始,过程中几乎没有重叠。

伴随着瀑布式的流程,代码也只有一份,“开发->改bug->发布”,周而复始。

直到去年10月,公司做了一场声势浩大的营销活动,灾难开始了:一方面需要以并不确定的研发周期支持各种运营活动(运营时间不等人,必须快速写快速发),一方面是运营活动带来大量客户,与客户相关的流程也陷入频繁修改发布的过程。此外支持各种终端需求也集中爆发,需要web侧快速跟进上线。当然,还有一个东西,就是上面瀑布流程中两周发布一次的“主版本”。当这么多版本交叠在一起时,我们发现必须要引入分支来管理研发过程。于是果断切Git。

使用PM2 Deploy部署基于Git版本管理的网站应用2014-11-19

按照官方介绍,PM2是一款用于生产环境Node.js应用进程管理的工具。按照民间介绍,它主要有这样几个功能:保证Node.js应用永远在线(挂掉自动重启)、自动负载均衡、零中断重启应用等。

鉴于它是如此优秀,这里还是简要介绍一下前两个功能。

安装

首先,它是一个Node.js写的工具,使用npm即可安装使用:

npm install -g pm2

运行Node.js程序

如果不使用pm2,运行Node.js程序是这样:

node xxx.js

使用pm2,是这样:

pm2 start xxx.js

监视模式

如果你正在开发Node.js应用,需要在代码变更后自动重启应用,只需要在pm2的参数中加上--watch即可:

pm2 start xxx.js --watch

如何高效debug2014-06-29

这是一个公司内网上的问题,原意是题主觉得debug非常费时,影响了项目的效率,问如何改进。当时也在内网随手码了几点,回头又看了一遍觉得很有共性,可以再扩展一下单独写写,于是诞生此文。因为专业所限,本文的部分细节也只限于web前端,但思路和其它语言是相通的。

首先,程序员要调整好心态。

事实上,debug是程序员工作的重要组成部分,甚至在产品的某些阶段是唯一的组成部分,所以不用把调bug看成是拖累产品进度、降低效率的凶手,这是一件必须要花时间认真去做的事情,它就是你的工作,也是整个项目进度过程中必不可少的组成部分。所以在debug的时候也可以更加平心静气一些,不用那么急躁。

当然,这个心态的改变也会涉及到项目进度安排上的一些调整,比如在排期的时候就要预估debug的时间,而不能仅仅只安排编码的时间。此外,还需要给自己做好时间管理,尽量能排比较大段的不被打扰的时间来debug。

把心态放平之后,有的bug可能解决起来真的就没那么耗时了。在心态平和、思路清晰、无人打扰的情况下,一般修起bug来都有如神助,效率高得连自己都不太敢相信。相反,往往越是着急的时候越是难定位到bug的真正原因。

Retina屏下的CSS雪碧图2014-03-19

CSS雪碧图早已经成为前端知识体系中一个必备知识了,时至今日,可能很多人都觉得这一块已经没有什么东西可以再讲了的。但事实上雪碧图一直都可以引出新的话题,比如从最早的连接数和体积的平衡到格式之争到图像摆放位置的策略,再到合并图像的颗粒度,再到内存占用、CPU占用等性能问题……

没错,今天还要在这一古老的话题上展开,引入一个新的问题,那就是雪碧图在retina屏下存在的问题及应对方案。(值得注意的是,retina屏一般指分辨率为普通屏幕两倍的屏,这样按照普通尺寸开发出来的网站相当于被放大了2倍,会导致图像模糊之类的现象产生,理想的解决方案是为retina专门适配一套皮肤,但本文关注的问题是未适配retina屏幕的网站所出现的问题。)

雪碧图本身不是浏览器或者web标准中的技术,因此它的不少细节取决于浏览器的实现,本文中的讨论的内容正是如此,为避免争议,本文所有结论的得出场景限定为Mac OSX 10.9.1、Chrome浏览器V33。是否适用iPhone、iPad等场景未做相应测试。

无处不在的白边

如前文所述,在retina屏上浏览未做专门适配的网站,会出现图像模糊等问题,无法达到最佳效果,但一般情况下,仍然处于可以接受的范围。不过,在某些网站上,却出现了比图像模糊更糟糕的情况:

WebQQ在retina屏下出现白边