刚刚查了 git， v 友中拥护者很多，我来一个槽点，恳请轻拍。

[1000copy]

一般流程涉及的命令还好，到需要撤销操作的时候，就有点乱。所以，我看到 git reset HEAD -- file.ext 这个幽灵般的子命令就有点蒙。

使用此命令，可以把 file.ext 移除暂存区。可是为什么不是 git unstage file.ext 呢。

命名应该体现语义， unstage 就是体现了语义的，在 pro git 一书中也建议通过自定义命令的方法，定义一个 unstage ，替代 reset 在此场景下的使用。 git reset HEAD -- file.ext 则是体现了它的实现。你要明白 reset 子命令是从 HEAD 之内取出 file.ext,使用此文件复写暂存区文件，从而达成把已经暂存的文件恢复成前一个版本的效果。为此，你就需要弄明白三个树的存储结构。等到钻入这个黑洞。我明白时，我已经把 tree 的三种存储搞清楚了。我就是这样任性的向偶像致敬的。

OMG ，为了连接 SQL ,你得弄明白关系数据库的存储——就是这个意思。

仿佛还不够复杂，于是还有：

1. git reset --hard HEAD
2. git reset --soft HEAD
3. git reset --mixed HEAD

可是在偶像目前，我不敢乱讲话的。所以，你不妨看看：

git reset

http://stackoverflow.com/questions/4114095/revert-git-repo-to-a-previous-commit?lq=1

原来并非我不懂。我不是一个人在战斗。

pro git 的作者也说，第一版本我没有说 reset ，是因为，我也不懂。妈蛋，把 git 这么个命令行版本工具写的和 c++ primer 差不多厚的人说我其实写完了一本书也不懂 reset 的。

另外， git add 是有多含义的，对于未跟踪的文件，可以用 add 把它变成已跟踪并且加入暂存区。对于修改的文件，可以用 add 加入暂存区。不同的场景功能是不同的。那么如何把一个未跟踪文件变成（仅仅变成已跟踪呢？我没有看到。 unix 的哲学是单一功能的命令，组合使用。一个多功能的命令未必合适。

我的意思：我对 CLi 的设计略有微词。也许我有些地方没有弄明白，请明白人指正。内部存储、暂存、分支、合并、 rebase 都很好的。

[msg7086]

你也有其他选择，比如 GUI 。安利下 SmartGit 。
GUI 的好处是他调用 Git CLI 的时候你可以在旁边学着，回头慢慢的你会学到不少奇淫技巧。

[msg7086]

另外，很多时候安利 Mercurial 就是因为 Git CLI 各种乱，虽然 Mercurial 也有自己的坑就是了。

[cyio]

@msg7086 +1 ，我就是这么干的

[cxbig]

操作上的一些不便利都是小事，提升团队协作效率才是关键性的优势。

[just4test]

add 操作其实可以视为 put 操作。

[old9]

安利下 gitsavvy

[clino]

"仅仅变成已跟踪"
是什么意思?我的理解并没有单纯的已跟踪这种属性,要变成已跟踪,总要有一个基本版本被加入 git 的数据库中,要么被提交到暂存区,要么已经被正式提交

[lightening]

git 的命令行已经被诟病多年了……

[chmlai]

Mac 可以用 gitup;
直接支持 command-z 来撤销

[SoloCompany]

add 其实还好，没有什么不一致，就是添加到暂存区，无论是添加删除修改状态都要 ‘ add' 到暂存区之后才可以 commit ，这个语意冲突就先不提了，其它的各种晦涩难懂，说反人类真一点不为过

[ChiangDi]

学会那几个常用的命令就可以应付 90% 的日常工作了

[menc]

看 github 客户端就知道，版本控制软件在够用的前提下能达到多好用。
什么常用的足够了
什么 gui 不需要
都是自己找罪受， github 的客户端究竟差在哪里？ sourcetree 究竟差在哪里？

[Sharuru]

一直认为 Git 用 GUI 来操作不要太爽～一排按钮点点点该有的功能都有了。

这么多命令行除非碰到疑难杂症不然一般真没 CLI 啥事。

顺便吐槽 SourceTree 越更新越难用（顺便还很丑）

安利下 GitExtension

[dcoder]

@1000copy
同意很多吐槽, 各个 git xxx 的语义有时找不到规律, 最后靠一个个的经验记忆