Posts Tagged ‘ git

关于Git的一点点忠告

周六的时候做了一个关于Git的讲座,其实我觉得每次讲座过后我自己都有很多进步,会暴露一些自己弄不懂的问题。这些问题可能原来自己并不在意,或者压根就没有研究过,在于别人的交流中这些问题都一股脑的蹦跳出来,让人无所适从。好在我脸皮比较厚,不太在意,这也体现了最近书中所学的“暴露缺点”的武林秘籍。

一个核心问题就是Git做分支太容易了,容易到了足可以影响到开发方式和开发习惯。这里罗嗦两句,说说量变到质变(以下省略一千字)。不过有个具体的例子还是和这个非常像的,那就是科学家用计算机证明了“四色猜想”,以及群的分类理论。啊哈~ 科学家把某种形式的证明变幻做了另外一种形式的计算,只要结果是什么就能证明什么。好吧,可能你有点晕了,简单来说只要你吹气超过20就证明你酒后驾车。

其实SVN做分支也是相对比较容易的,只不过checkout的时候很痛苦。Git的分支功能还是目前为止最高效的,因为git的分支,压根就不copy代码。总是觉得SVN在这点上非常让人难以接受,为什么Tag,分支都是目录呢?!更加可气的是居然还要复制。复制也就算了,居然还不记得从哪里来的。反观Git的分支实现,无非就是新建一个标记,几乎没有什么代价,所以大的项目也可以轻松的分支。Git会记录每个版本的来源,若是一个合并的节点,Git会保留合并的双方。这就是很多用SVN的同学要我演示若是已经合并了某个分支,对其再次合并会怎么样,哈,Git的给出的答案和正常人的想法一样:什么也不做,以为已经处理合并了,相关的冲突也解决了。这也是我为什么喜欢Git的一个原因,没有什么惊奇(最小意外原则),换句话说要是我设计Git,我也会这么做,自少在用户接口方面会这样做的。再次重申,我十分厌恶把Tag,分支和目录混为一谈。

很多人使用版本管理工具的功夫都是欠火候,不是因为他们记不住命令该如何使用,Git的最常用命令有21个,很不好意思,如果有人要我列举的话,我是答不上来的,我得看手册。这个问题有点怪怪的,哈哈,就好比我曾经问过好多天天写C程序的资深开发者:“C语言有多少关键字,请列举一下”,能答上来一半的就算多了。但这并不影响他们对每个关键字的理解。纵使你记住了全部32个关键字,大部分人还是写不出来什么像样儿的C程序。Git的情况也很类似。很多人知道如何分支,但不知道什么时候该分支,都会merge,但是不知道谁合并谁,由哪个角色来做,可能还有人会rebase,但是经常在不该用的时候用,结果就是一团糟。版本控制不是游戏,也不是随性的玩具想怎来就怎么来。我在讲Git的时候一再强调尽可能的分支,主干上尽可能就是合并的结果,尽可能不用rebase。当然这些都是些经验之谈,也没有觉得的准则,具体情况不同还是要具体来看。我只是希望大家不要把Git只是简单的看作一个工具,其实它是改造我们开发模式的一个实践。

我小学的时候老师给我们讲了一个故事(多半估计是杜撰的):一台非常精密的仪器坏掉了,现场的工程师怎么也找不到问题出在哪里了,挣扎了许久之后向一位这个领域的专家求助,专家到现场之后看了看机器,又要了图纸,沉思许久之后,在图纸上画了一条线。现场的工程师果然按照这个指引排除了故障,问专家的报酬是什么,专家回答说1000美元。很多人都觉得特别贵,觉得就画一条线根本不值,专家解释说:画一条线值1美元,知道画在什么地方值999美元。当年我十分单纯,记住这个故事纯粹是因为里面有好多钱,在我儿时那绝对是天文数字。现在想来我们的老师即便是杜撰了这个《读者》风格的故事来激励我们好好学习出人头地,我也十分佩服我的老师,他清楚的预见到了现在的社会故事中的价值观已经成为普世的了。我是想借着这个故事告诉那些整天琢磨奇技淫巧的程序员,知道怎么用Git并不重要,知道如何让Git提升你的项目管理水平才是最有价值的。