文章标签 ‘版本控制’

终于把git使用起来了,而不是照着书做练习,往往用在工作中才能会发现许多问题。因为原来使用svn比较多,总会忍不住和svn做比较,总结如下: 1。首先是概念的转变,svn是典型C/S结构或者说具有主从的概念,往往都是从服务器checkout代码再向服务器提交。对于git来说每个版本库都是平等,平等就相当于每个库都可以从其他库merge代码也可以提供给其他库自己的代码,这也符合git是一款分布式版本管理软件的概念。 2。版本管理软件的操作都差不多,无碍乎是初始化,checkout,checkin,然后提供一些显示diff,处理冲突,日志跟踪的功能。git比较有特点是存在暂存区的概念,任何修改都可以add到暂存区中,当然这个也没有太大必要,就是提交前的一个缓冲。当然也可以直接git commit <file>或者-a提交所以文件 3。在与远程库操作中git支持ssh,git和http三种协议,这对于linux用户来说事件好事,git的通信直接ssh即可,对于git协议通常用于只读的checkout因为它支持匿名访问。git的远程通信可以与svn做对比,git clone从远程库获取代码,通过git pull来更新代码,通过git push来提交更新(当然需要远程库同意)并且这些操作不是只针对一个远程库的(不像svn,从一个库checkout代码以后都只与这个库通信),通过git remote add可以添加其他远程库,并获取代码这也体现了分布式的概念。 4。在工作中还涉及带git和svn的通信,svn和csv的用户来说git可以无缝连接,git svn提供了丰富的方法,当然命令上也许有些差别。一般来说用git作为一种细颗粒度的版本控制,svn更多的作为一种存储仓库。git在版本的控制还是相当强大的。在使用git连接svn时,svn库最好是标准结构(即包含trunk,tags,branches三个目录)这样git svn clone -s可以很好的识别目录结构,我就碰到了一个没有很好结构的svn库,最后还是为了git重新整理的目录结构。git svn rebase命令同步svn库,其实是做了git svn fetch(先同步到本地远程库)和git rebase(关于rebase参看这里,今天看到的一句话上游merge,下游rebase,颇有意思) 5。有关编码问题,可以配置i18n.commitencoding和i18n.logoutputencoding ,我在gbk编码的机器上用iso-18859-1即可,这应该是对编码不做任何改动,所以提交和显示都是gbk。如果不做任何配置git会用utf8去encoding,必将出现乱。如果在utf-8的机器上查看gbk的log好像怎样都会出现乱码,我想应该是没有能把gbk转成utf-8的功能。不过最好都用utf-8或者都用同一编码的机器,这样就不用担心乱码了。 6。还可以配置全局的选项alias.XX “” 比如git config –global alias.ci “commit” git中没有把命令简化,这对于常用svn的人来说上手稍微不习惯,用alias可以很容易的解决这一问题。git中有关global的配置都在~/.gitconfig而库的配置都在.git/config中 先写这么多,git的命令之多是人难以想象的,这也能看出其功能之强大,很多用法我至今也不是特别了解,以后的心得继续补充。 文档: http://www.kernel.org/pub/software/scm/git/docs/ http://progit.org/book/zh/

2010年7月9日13:14 | 2 条评论
分类: 兴趣所在
标签: ,