我为什么更喜欢用Git

之前,我写了一篇文章《SVN为什么比Git更好》,主要是从非常朴实和现实的角度,从一个为全团队选型的角度,分析了为什么SVN比Git更好。但是公私分明,作为我个人来说,我想我还是更喜欢Git的。

Git

全分布式设计

分布式计算,早就是这个时代的趋势和潮流了,为什么版本控制不应该分布式呢?分布式到底有何好处呢?很多书会写,每个拷贝,都是整个版本库的镜像,(这是优点么?),灾难恢复比较容易,(因为每个人镜像的人,都是整个全部版本库,多少个人克隆,就等同于多少分备份,那么当然灾难恢复容易,不过这跟我到底什么关系?那是运维的事情),去中心化,(那又怎么样?写代码难道还要民主不成?),这些分布式带来的好处,感觉都有点隔靴搔痒的感觉。

那么我个人真正从全分布式设计中,获得的好处是什么呢?我更喜欢创建版本库,并且保存所有的代码了。因为任何时候,使用Git工作,都是持有整个版本库,从0开始创建一个项目,也不例外,当你执行Git init的时候,就是真正有了一个版本库了,过程容易的程度,让人印象深刻。如果,使用SVN,则完全不会这么愉悦,因为是CS架构的,所有你总是要选择一个Server,就算全本地的场景,你也不得不安装一个SVN Server的一些软件,创建完了版本库,还要网络连接,还要checkout,即便所有的东西在本地,这个过程也并不迅速。而一旦版本库建立在了本地,日后想要迁移,恐怕也有得痛苦,因为SVN本身不提供这种迁移机制。Git的话则完全不同,一旦你需要传输某个项目到某个版本库,使用remote相关指令,轻松搞定。

Git的这种设计,会激发我将一切代码的目录,都变成版本库,反正又没什么成本,能保证代码不丢还能记录版本,何乐不为?

分布式设计的另一个妙处,就是全离线操作,无论是提交代码,创建分支,切换分支,分支合并,几乎一切的一切,都是本地操作。所以,只要一台电脑在手,在任何地方,任何环境,我都可以愉快地写代码,在过去的日子,我觉得这似乎并不是什么真实的需求,但是时代发展到了当今,我确实经常带着电脑到处跑,而且,更加习惯带着电脑出门了,在今时今日,这已经完全是一个频繁的需求了。

更强大的功能

以前,在SVN下面,很多东西都被限死了。虽然减少了错误的概率,但是毫无乐趣,毫无掌控力,用着很死板。使用了Git,就感觉到了很多强大的东西,这让我爱不释手。

其中一个能力是分支创建和切换的简便。以前SVN的分支创建,首先是一个服务器行为,你必须发指令给服务器,漫长的等待,其次,切换分支也是很痛苦的,需要从服务器下载差异,哪怕新创建的分支,执行switch也需要很久的等待。其次,SVN提供了merge tracking技术,如果一个分支经过多次merge操作,恐怕就并不会给出那么喜人的结果了,会变得非常不智能,甚至需要手动填写精确版本号,才可以正确地合并,所以我们常见的做法是,用完一个分支回归trunk后,就删除分支,下次重开,可是开分支真的很耗时,尤其版本库大的时候,所以,程序员经常偷懒,时常在trunk直接改bug,这其实是冒了风险的。

第二个是改变提交记录的能力。在SVN,任何东西都是一次提交,创建分支,提交,删除分支,提交,合并分支,提交,变更代码,提交,撤销变更,再提交。会产生很多很多的提交记录。为了不让自己的一次变更散落在太多commit里面(提交历史记录很不好看),我经常做法是降低提交频率,这更是冒着很大的风险的。使用了Git,就完全不一样了,我可以随意提交,甚至运行脚本自动提交,而当我真的想要归档的时候,可以使用交互式rebase,将之前的提交都合并成一个,可以挑选一些连续的提交,将他们按照功能划分后,合并成一个,这样就会产生非常清晰而且有意义的提交历史,并且不会导致代码丢失。好爽。

Git的rebase是我喜欢的另一个功能,因为commit本身已经不是顺序自然数了,所以,调整commit的顺序,人是无法感知的,只能靠时间戳分清先后,在这种情况下,调整了commit顺序如果能让提交历史更清晰的话,真的太棒了,rebase就是干这个的,我经常独立开发一个分支,脱离主干太久,这时候我只要rebase一下主干,下次我的代码回归主干的时候,看起来就像是自然而然append到主干最后的几个提交一样,完全是线性而且清晰的历史,再经过我精心合并后,就能产生很美的效果。

强大民主的社区

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/16018.html