rubynroll

使用git已经有一段时间了,从使用git的第一天开始,就计划逐步放弃svn.

svn有的功能,git都能做到,而且做得更出色,况且git还有很多特性svn望尘莫及,还有什么理由继续使用svn呢?

well,理由很多. 比如,git在windows上的性能问题, TortoiseGIT还没有开发出来(或者根本没有这个计划?),团队中其它人员不习惯用git....等等.

那么,鱼与熊掌,能否兼得?

=== SVN 之痛与痒 ===

svn的最大问题是不支持分布式开发. 分布式并不一定就是指象Linux Kernel那样的大型协作开发场景.

例如,你想把没做完的工作带回家做,但是家里又不能连线到公司的svn服务器,那么你就不能commit. 实际上,这也是一种分布式开发的场景.

你会说,那你就不要commit啊 ... 我办不到, 我有个坏习惯,经常做些小改动,但是十分钟后就后悔了想改回来,只有经常commit我才能找回上次,上上次变更.

当然,我有坏习惯因此我不会commit到trunk或主branch上,否则会被扁死 :-)
所以,我经常有很多临时branch要merge,频率非常之高...在svn中的merge并不好玩.

不得不说,svn的repository设计很糟糕. 慢, 特别是在项目规模上去,开发周期长时,repository迅速膨胀.项目树中到处都是.svn也是很讨厌.

但是, TortoiseSVN实在是方便, 很多人使用SVN就是因为图这个方便.
支持SVN的IDE也数不胜数.

SVN,既痛又痒....

=== GIT 的威力 ===

git很快,真的很快,比小李飞刀还快...(当然是在Linux下).
试试checkout Linux Kernel的各个tag,那个速度,不得不佩服,呵呵~

其实对于小项目来说,速度倒无所谓,不差那么几秒,git还有很多cool things.

git diff很强大,真的很强大.比较任何两个历史版本,速度飞快.

git中做branch简直太简单了,branch merge也是非常的爽,更不用说three way merge了. 当然还有很多很cool的特性,例如,与别人的git tree进行merge ... 其实这些或多或少都是由于分布式的特性带来的.

还有那些通过email commit等等一般小团队开发用不到的功能,就不多说了.

=== 鱼与熊掌兼得 ===

首先,svn照用,主版本管理用svn(照顾团队嘛).

然后在项目目录下建git repository: git init.
这只在项目根目录下多出一个.git目录,不会象svn或cvs那样,每个子目录都有它的垃圾.

接下来,建立.gitignore文件,把不需要git管理的文件,加入此表,例如.svn. 或者进入.git/info编辑exclude文件.

加入git: git add .

完成了,就这么简单.

从此以后,小的,临时的改动,通通用git来管理,又快又准,还不影响别人. 因为你只用到本地git repository,与其他人无关.

各人建各人自己的git tree,互不干扰. 当然,如果你想日后某一天可以merge别人的tree,那么还是建一个bare public tree吧, 各人clone一个,然后工作在自己的branch下,平时还是照样离线commit,需要时push.

在家里工作?没问题,照样可以commit,git是分布式的.

回到公司后,想commit到svn?没问题,在git中checkout你想要的"working code"版本,再在svn中commit, 然后git再checkout HEAD,继续前行 :)

=== 结论 ===

svn和git结合, 可以带来以下好处:
1) 与单独使用svn的其它组员不冲突
2) 享受git分布式带来的好处
3) 可以满足svn commit working code的需求
4) svn大粒度管理,减轻svn repository的压力.
5) svn继续发挥GUI便利的优势.

所以, SVN + GIT = 鱼与熊掌兼得


有趣的是,Linus当时设计git的时候,说:"...当碰到一个特性不确定应该采取什么样的设计时,就只要照着svn的反方向设计就对了..."