Becomin' Charles

在我最新任职的团队里，我们采用Git正式作为我们团队开发管理的工具。我们使用Git来做版本控制，研发管理，和线上部署。我们将Git的版本库直接作为代码目录，来存放线上代码，发布的方法，就简化成了，将线上环境的代码目录，checkout 到指定的 tag，简单，快捷。

这个方法执行了一段时间后，发现一个新的烦恼，就是中央版本库的tag数量会变得非常多，多的时候，达到300多个，这其实也没什么了不起，但是我们自己采用gitlab来搭建自己的中央版本库，这个gitlab，还是很多bug的，当tag多了以后，整个网站都呈现出不是特别正常的样子，所以，就需要保持较少的tag列表，让网站保持比较高的性能。然后我就有了一个动机，就是删除远端的tag列表。

我用Google 搜了 how to delete git tags batch，发现老外的说法大概是，bulk delete，哈哈，英语不行啊。

无非就是shell下的一些做法，感觉实际使用上也够了。

首先就是找到远端要删除的tags列表，关键是用对指令。

1
2
3

git show-ref --tag

这个指令可以列出所有的远端的tag列表，然后就是shell下的一般处理手段了。

1
2
3

git push origin :

如上指令，会致使远程的tag被删除。用管道一连接，万事大吉。

1
2
3

git show-ref --tag  awk '/(.*)(\s+)(.*)$/ {print ":" $2}'  xargs git push origin

上面的指令就是拼接完整的指令了，不过这个指令，会删除远端所有的tag，慎用，如果希望删除符合条件的，应该修改awk指令的正则表达式。

删除完了远端的tag，本地的tag，删法还不是太一样，不过原理相同。

1
2
3

git tag  grep "v1.1.0.\d$"  xargs git tag -d

举个例子，上述命令删除本地所有 v1.1.0.x 的tag，这个指令，会最多删除10个tag。

在安装有些vim插件的时候，需要Vim支持Python，比如YouCompleteMe，但是，最近升级到Jessie后，发现，默认的vim，是不支持Python的，于是在网上搜索了一下，如果需要vim的二进制版本带有Python支持的话，应该安装一个叫 vim-nox 的包，其介绍为：

Vi IMproved - enhanced vi editor - with scripting languages support

就这样。

以前，我使用 Windows 作为自己的工作系统，后来，改用 Mac 作为自己的主要工作系统了。

在 Windows 下，快速搭建*AMP 环境，使用 xampp 或者 WAMP 之类的集成包，会一口气装好所有需要的软件，而在 Mac 下，相应的，做得比较好的是 MAMP，我选用的是与之对应的收费版本 MAMP Pro，总体差别不大。

前言

程序员圈子里流传着一个段子，说编程只有两个难题：缓存失效和变量命名。而我们中国有句古话，说：名不正则言不顺。这里面都提到了一个至关重要的问题，就是“取名字”。我认为，名字问题之所以如此重要，是因为，“名字”其实是对客观世界中实体的符号化表示。而这些符号，成为人类语言描述和思维的主要原料。如果名字有问题，就会严重干扰人类的思维。

Git——以及所有一切的版本库——的核心目标，就是保证代码不会丢失。我所熟知的两个版本控制工具——SVN和Git——都是通过提交代码（commit）来实现这个目标的。

虽然我反对使用SVN来类比Git，但是，如果仅是为了强调它们的“不同”，而进行比较，我觉得还是有助于理解的。

SVN使用过程中，版本仓库是在云端的，程序员的个人电脑上，只是一个工作副本，或者叫代码暂存，如果写好的代码，没有被送到云端的版本库，就意味着有潜在丢失的风险。所以，SVN的提交（commit），其本质，就是将代码从本地电脑传送到云端服务器，这个过程，我们称之为“入库”。

说实在的，Git我已经学习了很久很久，从最开始的，零星的学习，然后偶尔使用，到现在成为公司的唯一版本控制方式，断断续续没有两年，也有三年。Git官网上写着，简单易用（easy to learn），我就是被这四个字骗了，开始用上了Git。现如今，它已经成为一种避无可避的工具了，必须学会。

要开始上手使用Git，可能真的是很简单的事情，如果你翻开一些成体系的文档或者书籍，可能上来会教你使用git init命令。这个命令的目的是创建一个新的git版本库。但是，就我个人的经验来看，一个新人，接触版本控制系统，可能第一件事情，往往是融入一个开发团队，接手一块业务，然后开始贡献代码，不太会是上来先建立一个版本库。

Git是目前世界上最为炙手可热的版本控制系统。它是如此的流行和重要，以至于全世界程序员的工作和生活，都可能因之而改变。

Git是一个版本控制系统，帮助程序员管理自己的源代码的版本变化，保证它们不会丢失。它只是开发工作中的一个工具。但是，一个“工具”，为什么可以重要到足以改变这个“工作”本身？我们可以以政治经济学范畴的概念，来理解一下这个问题，Git就相当于是生产工具，生产工具的发展，可以进一步解放生产力，从而推动了社会的进步。Git不是历史上第一个版本控制工具，显然也不会是最后一个，为什么到了Git出现的时候，就产生了近乎变革般的变化？

学习使用PHP怎么也有7年的时间了，竟然也没有注意到有个函数是array_replace_recursive，之前只知道array_merge_recursive，而且，这两个函数的返回结果，都非常地出人意料，不怎么符合直觉，而使用了Yii框架若干年，竟然也不知道有个CMap::mergeArray()方法，这个方法，如果跟前面两个函数混同起来看，竟然也显得有点离奇。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

 [
 'apple',
 'orange'
 ],
 'nested' => [
 'A' => 'xx',
 'B' => 'yy'
 ],
 'single' => 1,
];
$b = [
 'fruite' => [
 'penapple',
 ],
 'nested' => [
 'A' => 'zz',
 ],
 'single' => [
 'string'
 ],
];
echo "array_merge_recursive: ", PHP_EOL;
var_export(array_merge_recursive($a, $b));
echo PHP_EOL, "array_replace_recursive: ", PHP_EOL;
var_export(array_replace_recursive($a, $b));
echo PHP_EOL, "CMap::mergeArray: ", PHP_EOL;
var_export(CMap::mergeArray($a, $b));

然后，我们来看一下这个用例输出的结果，相当神奇哦~

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

array_merge_recursive: 
array (
  'fruite' => 
  array (
    0 => 'apple',
    1 => 'orange',
    2 => 'penapple',
  ),
  'nested' => 
  array (
    'A' => 
    array (
      0 => 'xx',
      1 => 'zz',
    ),
    'B' => 'yy',
  ),
  'single' =>                //注意这个东西的处理，简直莫名其妙！
  array (
    0 => 1,
    1 => 'string',
  ),
)
array_replace_recursive: 
array (
  'fruite' => 
  array (
    0 => 'penapple',
    1 => 'orange',
  ),
  'nested' => 
  array (
    'A' => 'zz',
    'B' => 'yy',
  ),
  'single' => 
  array (
    0 => 'string',
  ),
)
CMap::mergeArray: 
array (
  'fruite' =>   //这里选择了array_merge_recursive的行为
  array (
    0 => 'apple',
    1 => 'orange',
    2 => 'penapple',
  ),
  'nested' => 
  array (
    'A' => 'zz',
    'B' => 'yy',
  ),
  'single' =>   //这里却选择了array_replace_recursive的行为
  array (
    0 => 'string',
  ),
)

实在是没有心力去把所有的用例想完整，只能随便写几个，从中可以看出来，这些函数的处理规则，不是简单可以说清楚的。

1. 对于包含了字符串键的数组，是逐个键去做merge或者replace的
2. merge：对于键的值都是纯数组的情况，单纯合并
3. merge：对于键的值都是非数组的情况，创建数组添加两者作为元素
4. merge：对于键的值一边是数组，另一边是非数组，结果就匪夷所思了，将数组降维后，按上一条规则处理
5. 相比之下，replace的行为更具被一致性，就是纯替换
6. CMap::mergeArray 则跟两者的行为都有所不同，我也是跪了

当然，问题绝不止这么几个，只是我懒得想全所有用例而已。

之前已经写了蛮多的跟这个事件驱动特性有关的内容了。比如我今天发现，Yii 框架支持的事件驱动，只能支持对对象实例进行事件绑定。简单来说，当你要绑定某个事件的时候，这个事件的触发者的对象，必须已经建立好了。

Yii框架的特性列表里，有一项叫“Event Driven”，所谓的事件驱动，但是在实际业务开发实践中，我发现即便有应用场景，大家也倾向于不用，究其原因，还是不熟悉。

当然，我认为，作为Yii框架的官方开发团队，没有在这方面给出充足的，合适的例子，来说明这个特性的使用场景，也有着不可推卸的责任。

生搬硬套，为了使用event而去使用event，这种是我们坚决要杜绝的行为，那么到底在哪里使用这个特性才显得恰如其分呢？当然，笔者也没有一个非常好的标准去判断，只是偶有所得，在此跟大家分享一下。