之前一直用SVN做项目开发，确实感觉这些版本控制工具非常实用，尤其是在一个团队开发项目的时候。最近偶然看到一个新的版本管理工具Git，它本来是Linux下的基于Linux内核的版本控制工具，据说用起来比SVN既快，又功能强大，现在在Windows下又有了TortoiseGit，是SVN小组开发的基于Git的在Windows下的版本。网上找了些资料看了看，发现确实很牛很强大啊，资料汇总如下
优酷上有关于TortoiseGit的安装方法和基本使用技巧，介绍的还行，但先别急着按里面说的安装，有注意的地方后面一个资料里会提到
介绍为什么要用Git取代SVN，可以简单看一下Git的优点
这个是介绍如果不想放弃SVN，可以SVN为主，Git为辅的方法，所谓鱼和熊掌兼得
关于TortoiseGit的安装方法，这里介绍的非常详细，注意事项等各种截图，可以按着一步一步来
注意事项就是，不要让Git往windows右键菜单里添加菜单项，因为TortoiseGit会产生的，设置如下
还有一个就是如下设置，有人建议使用第一个，否则可能引起与windows的不兼容等问题
还有下面的选项，网址上选了第三个，这样Git就不会改变换行风格了，但从它的解释看，第一个更适合扩平台操作，不过也没关系，这个似乎可以在后面安装完后修改
然后就是TortoiseGit的安装了，有一个要注意的就是下面这个选项，选第一项就行了，关于这个在有解释，摘抄如下：
TortoiseGit 可以支持 SSH 加密方式的“上传”，早期版本是借助另一款专门实现 SSH 传输的开源软件 来实现，用户必须另外安装 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）文件，每一个服务器都不一样。请参看 ，本文不再赘述。
不过别担心，我们只想通过 TortoiseGit 来下载软件最新版本，就不需要搞清楚这个 Key 是什么，怎么用，一样能达到目标。
安装完后会要求重启。
然后就是关于TortoiseGit的设置和使用了，可以参考
这里是有关TortoiseGit的入门及它的一些版本管理的思想，感觉几张图给的挺好的（里面介绍的基础命令感觉不用管，反正使用的也是图形界面）
下面把它介绍基于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 review3.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!
另外还有一个中文教程，貌似是Linux下的，这里收藏一下链接吧
