Git管理工具对比（GitBash、EGit、SourceTree）
GitBash是采用命令行的方式对版本进行管理，功能最为灵活强大，但是由于需要手动输入希望修改的文件名，所以相对繁琐。
EGit是Eclipse的Git插件，最为纠结的一个软件，因为开发时直操作很方便，尤其是有svn开发情节的人更热衷于这样，不过EGit中有很多bug和不人性化的东西，让人吐血，所以
一句话EGit并不能解决所有Git问题，开发时必须部分依赖于其他Git管理工具。一会一一列举。
SourceTree是最近应用的一个软件，一句话概括，既有GitBash的命令行，又有EGit的图形化管理，用户界面很人性化，Eclipse+GitBash完全可以应付版本管理。
那么下面我结合项目中开发遇到的问题一一讲解一下：
）。
图（1）
B. 然后再次修改，发现下面的工作区中也有这个页面了（图2）。
（图2）
C. 现在就可以对此文件进行丢弃了，如果将下面文件丢弃（checkout），那么该文件将变为缓冲区中的文件，如果将缓冲区文件丢弃，实际上回到了最近的commit版本了(reset操作)。
这里注意，如果该文件commit了，那么checkout实际上回不到commit之前的版本的，需要reset。下面详细介绍一下reset命令。
(5) 对于reset功能的应用。这里先普及一下Git理念的事：
A. 明确一点，每一次commit都是对应着一批操作而不是对应一个文件。
这点和SVN的设计理念完全不一样。
这也造成了一个必然的结局：SVN的分支存的是一个工程，所以每签出一个分支实际上都是签出一个工程。
而Git的分支存的是修改的记录，所以每签出一个分支，实际上都是对原工程的一次覆盖。
B.在开发过程中大家可能会遇到这样一个问题：Pull之后，会出现很多别人提交的代码需要你本地再重新提交一次，那么这个原因是这样的，当然这个是我个人的理解：Git会把每一次pull结果做两个处理：
B1.如果pull之后，本地没有任何问题，那么不需要再次提交别人修改的东西了，只需要继续你的修改，push就可以了（正常情况下一版都是这样）。
B2.如果pull之后，本地有问题，大部分情况是冲突的情况，那么Git会把本次当做一次不成功的pull（那么通俗的来讲，git会认为，你认为不成功，那么你把这次版本按照你的想法改一下，再提交吧），所以你做完删减之后，需要把刚才别人的东西再提一次作为一个新的commit。
(6) 对于checkout某一次提交，SourceTree也很人性化，会给出很人性化的提示。注意checkout之后，你的工程当前不属于任何分支，不过可以基于此重新创建一个分支，很方便。
总结一下：这里只列出了一些关键的问题和不同点，当然工具的选择因人而异。大家可以在工作中慢慢体会，如果有问题欢迎大家提出，给我宝贵的意见。（待续）