让你不仅用上、更用明白的 Git 实用指南
随着这几年 GitHub 的流行，Git 已经是一个程序员逃不过的技术项，但很多人却纷纷倒在了学习它的路上。而且，出于工作原因而不得不用 Git 的人，有不少在工作中对 Git 也是能不用就不用，生怕哪个命令用错就把公司的代码库毁掉了?。而那些对 Git 掌握得比较好的少数人，就像团队中的神一样，在同事遇到 Git 相关的问题的时候用各种风骚操作来拯救队友于水火。
学不会、学不好 Git 的人，其实多数并不是不愿意学。很多人都会尝试去网上找 Git 教程、去社区请教高手、在公司咨询同事，但转了一大圈下来，依然没有搞懂，甚至有可能越来越糊涂。
– 你刚才输入的这个 Git 指令是什么意思？
– 意思是 XXX。
– 可你上次跟我说它的意思是 YYY 啊？
– 嗯对，不同的场景不同的用法，上次是 YYY。
– ……好吧。另外你上次帮我解决这个问题用的是另一个指令 zzz 啊？
– 嗯对，那个也能解决，但这次用这个指令更适合，因为 @#￥@%*&。
– ……
– 懂了吗？不懂的话还可以问我，没事的。
– ……
Git 学习到底难在哪？
Git 的学习曲线很不友好：想上手很容易，只要学会 commit、push、pull 等几个指令，就能够初步地使用它；但如果想要更进一步，让自己能够在团队项目中和朋友或同事自由合作，却又很难。
那么 Git 到底难在哪呢？
其实关键在于一点：概念。
Git 的概念，是由一套完整的思维逻辑所构成的。 你不能从多个角度分步理解它，而是要把它作为一个整体一下子吃掉；而同时这个「整体」由于过于复杂，又实在有点难以一口吞。颇有点悖论的意味。
很多人在使用 Git 一段时间后，会觉得 Git 有点复杂和混乱：
– 为什么要 commit 后再 push 这么啰嗦，而不能直接提交到中央仓库？
– reset 这个指令为什么这么神奇，好多看起来并不相似的操作却都要用到它？它到底是干嘛的？
– revert 和 rebase 都可以撤销历史提交？它们的区别在哪？什么，你说 reset 也行？
类似的问题其实还有很多。这些问题看起来每个都很难，但只要你把 Git 的概念了解了，这些问题（以及那些许许多多我没有列出来的问题）就全都迎刃而解了。
学懂了概念，就能学懂 Git，就这么简单。可是市面上的很多 Git 教程都只停留在了 Git 的使用上，而对它的概念却总是一笔带过或干脆提都不提。这里的原因，我猜可能是因为它的概念太难讲清楚了，也可能是因为这些作者其实也对 Git 的许多概念并不够了解吧（这句是胡说八道，Git 教程的作者们请放下手中的枪）。
