但是实际使用过程中有一些小小的意外流程，完全照搬git flow的模型不太容易处理好。好在git本身就很灵活，碰到问题基本上都有办法绕过去。下面是我总结的一些特例情况下的处理办法。

测试/共享单独一个feature

有时候我们需要将一个feature独立测试，或者share给多人一块开发，那么可以将这个feature推到远程git库上，这可以利用git flow的publish功能搞定:

git flow feature publish my_cool_feature

这会将 feature/my_cool_feature 分支push到远程git库，多人开发或者单独测试毫无压力。

feature在development分支测试完成，准备release的时候有另外一个未经测试的feature合并进来

已经完成测试的development被未经测试的提交污染了，这时候可以先本地回滚development分支，然后再进行git flow的release流程，例如:

git checkout development
git reset --hard 5cbadfe885d1eb514b3f07b3f269ca1a7f261e21   #假设测试通过的git rev是这个
git flow release start v1.0.1
git flow release finish v1.0.1

development上有个feature需要测试比较长时间，影响了一些耗时较短的feature发布

development分支上有个feature测试时间比较长一直释放不了，怎么办？—— 果断采用hotfix功能

git br -m feature/another_cool_feature hotfix/another_cool_feature

把耗时短的feature直接转换为hotfix，然后采用git flow的hotfix流程可以直接合并到master分支发布。

在远程服务器的设置

假定你需要部署的代码在/var/www/yoursite

cd /var/www/yoursite
git init .
git config receive.denyCurrentBranch ignore
git config --bool receive.denyNonFastForwards false
cd .git/hooks
wget http://utsl.gen.nz/git/post-update
chmod +x post-update

在本地git库中新增配置

[remote "prod"]
        url = your-ssh-username@your-host:/var/www/yoursite/

这样就算设置完成了。

如果你想把本地的代码推送到远程服务器，下面简单的步骤就可以做到

git pull
git push prod

注意事项

如果远程服务器上git的配置目录.git暴露在外部可访问的位置，请在web服务器上设置这个目录不可见。

照着这个思路，捋起袖子就开干了。

用git-svn抓取插件代码

wordpress的插件svn库大且缓慢，如果直接用git-svn去clone代码，一定会慢死，所以我按照以前的笔记，用git从大型svn快速clone代码。

以code-prettify插件为例，首先需要读取这个插件创建时的版本号

svn log http://svn.wp-plugins.org/code-prettify|tail -4|head -1

得到了如下信息，获得一个版本号 318479

r318479 | plugin-master | 2010-12-03 20:12:29 +0800 (五, 03 12 2010) | 1 line

开始clone代码

git svn clone -s --prefix=svn/ -r318479:HEAD http://svn.wp-plugins.org/code-prettify

设置git仓库

首先把代码传了一份到github: https://github.com/volca/code-prettify

然后操作本地git仓库

git branch -m svn
git remote add origin git@github.com:volca/code-prettify.git
git checkout master

本地svn分支对应svn的远程仓库，本地master分支对应github的远程仓库

Happy time

现在可以按照平常的习惯在git下更改代码，然后用git push到github上。

如果需要更新代码到svn上，按这个流程操作就可以了：

git checkout svn
git merge master
git svn dcommit

如果需要发布wordpress插件的新版本，这个在svn里就是一个打tag的过程，用git-svn操作非常简单，下面的例子表示发布code-prettify插件的0.3版本：

git svn tag 0.3

1. 把Consistent Hashing算法换成了ketama，在pecl的memcached扩展里有简单方法可以实现，效率比单纯的php好很多，能快个10倍吧。没有重复造轮子，因此我很是得意。
2. 静态方法调用时，不再支持原来的system参数，原版是用这个来支持多个LiteCloud集群。
3. 第一个版本，利用memcached扩展来读取tokyo tyrant，所以目前仅支持简单的操作比如get, set, delete, increment。其实再努力一下，也可以支持更多的功能，比如redis。
4. 去掉了原版的local_cache功能，我觉得这个功能完全可以放在外面，更灵活。

项目主页

目前托管在github上 —— LiteCloud ，使用git以及github的时间不太长，但是很喜欢，欢迎fork。

使用示例

用静态方法调用:

require 'LiteCloud.php';

$config = array(
    'lookup1_A' => '127.0.0.1:41201',
    'lookup1_B' => '127.0.0.1:51201',

    'storage1_A' => '127.0.0.1:44201',
    'storage1_B' => '127.0.0.1:54201',
);

list($lookupNodes, $storageNodes) = LiteCloud::generateNodes($config);
LiteCloud::init($lookupNodes, $storageNodes);

LiteCloud::set('hello', 'world');
print LiteCloud::get("hello"); # => world
LiteCloud::delete("hello");

print LiteCloud::get("hello"); # => nil

或者采用实例化的方式调用，这种方式能够支持多个LightCloud集群

require 'LiteCloud.php';

$config = array(
    'lookup1_A' => '127.0.0.1:41201',
    'lookup1_B' => '127.0.0.1:51201',

    'storage1_A' => '127.0.0.1:44201',
    'storage1_B' => '127.0.0.1:54201',
);

$cloud = new LiteCloud($config);

$cloud->set('hello', 'world');
print $cloud->get("hello"); # => world
$cloud->delete("hello");

print $cloud->get("hello"); # => nil

看上去和python版本差不多，对吧？

性能测试

这个部分是个重点，之前找到的lightcloud的php版本，性能比原版要慢一个数量级，我可不想在这个地方丢了份。

暂时做了个最简单的性能测试，测试脚本在test目录下。测试条件如下:

1. 底层采用tokyo tyrant作为存储。
2. 单个进程重复操作一万次，比如写一万次hello => world，这个测试条件和python版本完全一致
3. 关闭了local_cache

python版本的测试结果

Finished "Tyrant set" 10000 times in 2.50 sec [4002.0 operations pr.sec]
Finished "Tyrant get" 10000 times in 1.04 sec [9583.7 operations pr.sec]
Finished "Tyrant delete" 10000 times in 7.39 sec [1352.4 operations pr.sec]

LiteCloud的测试结果

Using 1.8229308128357 time to set 10000 values. QPS:5485.67
Using 0.71097207069397 time to get 10000 values. QPS:14065.25
Using 2.1550960540771 time to delete 10000 values. QPS:4640.16

看上去还比较乐观，尤其是delete的性能翻了好几番，几乎要怀疑我在代码实现部分出了差错，在其它方面的表现也是全面超出，因为python版在hash_ring的实现上拖了后腿。

git-review为git新增了一个很方便的代码review途径，利用这个命令，可以调用别的工具比如vimdiff来review代码的改动。下面简单记录一下使用的过程：

下载并安装

首先确认已经装好了git，剩下的事情比较简单。

git clone git://github.com/facebook/git-review.git
cd git-review
python setup.py install

这几步为git新增了一个review命令。

git-review的使用

查看指定版本的改动

git review 58e2fb834793f5c6c1fdd900a1c0224a44735962

出现提示

Now processing modified file foo.php
foo.php [diff]>

由于我配置了diff工具为vimdiff，所以接下来就可以用vimdiff查看foo.php在58e2fb834793f5c6c1fdd900a1c0224a44735962这个版本与最新版本之间有什么不同。

查看两个版本之间的改动

git review 5b744bdc5f5bcbcfd6bb65f815aebe6bdce8c427 58e2fb834793f5c6c1fdd900a1c0224a44735962

在review每个代码之前，都可以使用help查看git review命令的帮助，如果放弃review，那么直接敲退出就可以了。

当时还想着能不能hack一下git-svn脚本，其实后来看看文档，clone操作可以使用参数-r$REVNUMBER:HEAD检出指定版本后的代码，因此，更好的步骤应该是这样：

• svn info http://your-svn, 并记录最后的版本号，假设是260
• 假设要检出最后10个版本，做个简单的减法： 260 – 10 = 250
• 开始clone操作了

  git svn clone -r250:HEAD --prefix=svn/ http://your-svn

按这个办法，clone的时间的确是减少了许多。

目前在windows下，最好的git客户端恐怕就是装一个cygwin。鼓捣了一个时辰，整理好一些可用的配置文件，陈列一下以备下次使用：

~/.bash_profile

偶尔还会使用svn验证一下check in的情况，刚转过来不放心啊，下面的配置是为了防止svn命令行乱码。命令行git-svn在/usr/sbin/git-core/路径下，是一个perl脚本，为了方便，我把这个路径加入了PATH环境变量。

export PATH=$PATH:/usr/sbin/git-core/
export SVN_EDITOR=vim
export LC_ALL=en_US.UTF-16
export LC_CTYPE=en_US.UTF-16
export LANG=en_US.UTF-16
export XMODIFIERS=@im=Chinput3
stty cs8 -istrip
stty pass8
export LESSCHARSET=latin1

~/.inputrc

去掉注释即可

set meta-flag on
set convert-meta off
set input-meta on
set output-meta on

~/.gitconfig

[user]
name = muhaha
email = aa@bb.cc

[color]
diff = auto
status = auto
branch = auto

[alias]
st = status
rb = svn rebase
ci = commit -a
co = checkout

常用操作