之前一直用SVN做项目开发,确实感觉这些版本控制工具非常实用,尤其是在一个团队开发项目的时候。最近偶然看到一个新的版本管理工具Git,它本来是Linux下的基于Linux内核的版本控制工具,据说用起来比SVN既快,又功能强大,现在在Windows下又有了TortoiseGit,是SVN小组开发的基于Git的在Windows下的版本。网上找了些资料看了看,发现确实很牛很强大啊,资料汇总如下
优酷上有关于TortoiseGit的安装方法和基本使用技巧,介绍的还行,但先别急着按里面说的安装,有注意的地方后面一个资料里会提到http://www.youku.com/playlist_show/id_5227985.html
介绍为什么要用Git取代SVN,可以简单看一下Git的优点http://www.joomlagate.com/article/joomla-review/why-subversion-will-be-replaced-by-git-for-version-control/
这个是介绍如果不想放弃SVN,可以SVN为主,Git为辅的方法,所谓鱼和熊掌兼得http://rubynroll.iteye.com/blog/203133
关于TortoiseGit的安装方法,这里介绍的非常详细,注意事项等各种截图,可以按着一步一步来javascript:void(0)
注意事项就是,不要让Git往windows右键菜单里添加菜单项,因为TortoiseGit会产生的
还有一个就是如下设置,有人建议使用第一个,否则可能引起与windows的不兼容等问题
还有下面的选项,网址上选了第三个,这样Git就不会改变换行风格了,但从它的解释看,第一个更适合扩平台操作,不过也没关系,这个似乎可以在后面安装完后修改
然后就是TortoiseGit的安装了,有一个要注意的就是下面这个选项,选第一项就行了,关于这个在javascript:void(0)有解释,摘抄如下:
TortoiseGit 可以支持 SSH 加密方式的“上传”,早期版本是借助另一款专门实现 SSH 传输的开源软件 Putty 来实现,用户必须另外安装 Putty,然后在 TortoiseGit 的设定选项中给出 Putty 的可执行文件位置(例如 C:Program FilesPuttyplink.exe)。现在最新的 TortoiseGit 已经自带了 TortoisePlink.exe(在右键菜单中 TortoiseGit -> Settings -> Network -> SSH -> SSH client)。
TortoisePlink.exe 实际上是 Putty 的 Plink.exe 文件的一个衍生产品,功能上比 Putty 可能要差一些。如果你喜欢 SSH 方式,那么还是建议你安装 Putty —— 没准你的电脑上早就安装了。
提示:通过 SSH 方式访问远程服务器还需要认证密钥(Putty Key)文件,每一个服务器都不一样。请参看 Putty 的相关文档,本文不再赘述。
不过别担心,我们只想通过 TortoiseGit 来下载软件最新版本,就不需要搞清楚这个 Key 是什么,怎么用,一样能达到目标。
安装完后会要求重启。
然后就是关于TortoiseGit的设置和使用了
这里是有关TortoiseGit的入门及它的一些版本管理的思想,感觉几张图给的挺好的(里面介绍的基础命令感觉不用管,反正使用的也是图形界面)http://hi.baidu.com/eehuang/blog/item/37af8d54242d6351564e00b5.html
下面把它介绍基于git的合作开发的部分拿来摘抄一下:
对于酷讯来说,当我们采用了Git,如何进行合作开发呢? 具体步骤如下:
3.1 获取最新代码
酷讯会准备一个中心git代码库。首先,我们将整理好的代码分模块在git中心库中建立git库。并将文件add到中心库中。 接下来,开发者通过git-clone将代码从中心库clone到本地开发环境。
对于较大的项目,我们还建议每个组选择一个负责人,由这个负责人负责从中心库获取和更新最新的代码,其它开发者从这个负责人的git代码库中clone代码。此时,对开发者来说,这个负责人的git库就是中心库了。
3.2 开发者在本地进行迭代开发
当用户将代码clone到本地后, 就可以进行本地的迭代开发,建议用户不要在master分支上开发,而是建立一个开发分支进行开发。 在本地开发中,用户可以随意的创建临时分支,随意commit。
3.3 开发者请其它同事进行code review
当本地开发完毕,可以请其它同事进行code review。过程为:
1. user2通通过git-pull命令,将开发者(user1)的开发分支(dev)pull到user2本地的一个tmp分支,并切换工作分支到该分支上进行code review。
2. 完成code review后, user2切换回其原有开发分支继续开发,并告知user1已经修改完毕。
3. User1将user2的tmp分支git-pull到本地tmp分支,并和dev分支进行merge。最终得到一个code review后的dev分支。
当然,user2也可以直接坐在user1旁边在他的代码上进行review。而不需要走上述步骤。(图中第7步,不是git-pull,而是直接在dev分支上和user1边review边modify)
3.4 和中心库进行代码合并
使用过CVS的人都知道, 在commit之前,都要做一次cvs update,以避免和中心库冲突。Git也是如此。
现在我们已经经过了code review, 准备向中心库提交变化了, 在开发的这段时间,也许中心库发生了变化, 因此,我们需要在向中心库提交前,再次将中心库的master分支git-pull到本地的master分支上。并且和dev分支做合并。最终,将合并的代码放入master分支。
如果开发过程提交日志过多,可以考虑参照2.10节的介绍做一次git-reset。
此外,如果发现合并过程变化非常多, 出于代码质量考虑,建议再做一次code review
3.5 提交代码到中心库
此时,已经完全准备好提交最终的代码了。 通过git-push就可以了。
3.6 合作流程总结
大家可以看到,使用git进行合作开发,这一过程和CVS有很多相似性,同时,增强了以下几个环节:
1. 开发者在本地进行迭代开发,可以经常的做commit操作且不会影响他人。 而且即使不在线也可以进行开发。只需要最后向中心库提交一次即可。
2. 大家都知道,如果CVS管理代码,由于我们会常常做commit操作。但是在commit之前cvs update时常会遇到将中心库上的其它最新代码checkout下来的情况,此时,一旦出现问题,就很难确认到底是自己开发的bug还是其它用户的代码带来了影响。 而使用git则避免了用户间的开发互相影响。
3. 更有利于在代码提交前做code review。 以往用cvs, 都是代码提交后才做code view。如果发生问题, 也无法避免服务器上有不好的代码。 但是用git, 真正向中心库commit前,都是在本地开发,可以方便的进行code review, 然后才提交到中心库。更有利于代码质量。而且, 大家应该可以感到,使用git的过程中,更容易对代码进行code review,因为影响因素更小。
4. 创建多分支,更容易在开发中进行多种工作,而使工作间不会互相影响。 比如user2对user1的代码进行code review时,就可以非常方便的保留当时的开发现场,并切换到user1的代码分支,在code review完毕后,也可以非常方便的切换会曾经被中断的工作现场。
诚然,带来这些好处的同时,确实也使得操作比CVS复杂了一些。但我们觉得和前面所能获得的好处相比,这些麻烦是值得的。 当大家用惯了之后会发现,这并不增加多大的复杂性, 而且开发流程会更加自然。请大家多动手,多尝试! 去体验git的魅力所在吧!let’s enjoy it!
青春就应该这样绽放 游戏测试:三国时期谁是你最好的兄弟!! 你不得不信的星座秘密