为什么Git的教程都那么繁杂？
Git的内部原理并不是很复杂，弄清楚四种对象和ref以后，几乎所有Git作都可以在脑海中具象化。但是Git的教程的确很繁杂，我反复阅读的教程包括文档和ProGit，都算大部头，有些细节部分讲得不清楚的地方，还会在网上搜下大神们写的博文。
当你觉得所了解的Git知识已经够用的时候，大概率是因为你的工作和学习场景中只需要用到这些知识。对于很多码农来说，知道gitadd,gitcommit,gitpush,gitpull就已经够了。但是如果去看这几个命令的帮助文档，会发现里面洋洋洒洒一大堆东西。那些你觉得已经不需要了解的内容的对你毫无帮助吗？
有同事问过我这样一个问题：在一个文件里修改了好多内容，但是提交的时候只想提交其中一部分，该怎么做？我问他平时遇到这种情况是怎么处理的，他的做法是这样：把修改好的文件复制一份，然后把原本的文件修改全部回退掉，接下来再用eyondcompare对2个文件，将其中要提交的那一部分修改合并到原本的文件里，合并完要的部分之后再提交，提交完了以后，再把剩余的修改通过eyondcompare合并过去。这种做法完全可以解决他的问题，但是他明显觉得不够方便，码农的直觉告诉他Git应该有什么方法可以处理这个问题，但他又不知道具体要怎么做。
命令行的话利用gitadd的-p/--patch参数可以很方便地解决这个问题，按几下键盘就可以。而很多GUI工具里应该也有类似作，看起来还更加友好。我跟他说了这个方法以后问他，如果他在没有eyondcompare这类工具且只能使用命令行的环境里遇到这种情况要怎么办。他说那只能备份以后，回退再手动再改一遍了。的确，条条大路通罗马，只是有的平坦，有的崎岖。对于一般用户，如果能深入的了解和学习下常用命令的参数和作方法，很可能会带来很多便利。
用的多了，会遇到很多类似的场景。举几个的例子，都是实际遇到过的问题，想下是否能通过git本身提供的机制去解决，能想到几种处理方式，这些方式有什么优劣？
现在很多和工具都把Git作为工具链的一部分，当你使用这些和工具的时候，避免不了要和Git打交道。而且遇到的场景远“提交代码”要复杂很多。譬如你们团队要对每一笔提交进行自动化构建，并将结果存储起来，如果有错误的话要记录下来通知处理。你们团队把这个任务交给了你。你研究以后发现，搭建个jenkins就可以实现这个需求了，利用jenkins的Git插件和钩子push事件，然后克隆仓库检出分支进行构建。那这个时候你就要去了解githook是怎么回事，但是假如你们使用的代码托管平台是Gitla，还要学习wehook是怎么回事。当你把这些搞定以后，自动化构建任务也顺利的跑了起来。团队把这个当作一个增效案例报了上去，团队看了以后说这个挺好的，把我们负责的仓库也加进去吧。于是这个自动化构建规模越来越大，终于有一天用户反馈构建任务越来越慢，还经常报错，什么执行构建任务的上文件变成只读了、空间不够了、克隆仓库速度很慢。这个时候你又会要去了解有什么办法可以让克隆仓库速度变快并且要节省空间。在gitclone和gitsparsecheckout相关的文档里找到线索后，你又很好地解决了这个问题，然而又接到了新的需求：团队希望有个前端页面，用户可以在里面自己配置仓库、分支之类的参数，然后后台任务根据这些配置自动去跑，而不用每次都通过你手动去jenkins上改配置；此外团队的需求也越来越丰富，你的构建脚本也越来越复杂。作为精通前后端的全栈开发，你又接下了这个任务。你在脚本和代码里用到了越来越多、越来越复杂的Git命令，通过命令行的方式满足不了需求了，你又学习了jgit和gitpython的使用方法，并将它们用到了你的脚本和代码里。在此期间，你可能还学习了gitignore，pathspec，gitattiute之类的知识，学习了如何用底层git命令手搓commit。最终，你成为了一个Git资深用户，而对于Git本身的贡献，可能仅仅是提了一些issue，并没有的参与到修改Git源码中去。
从最初只要利用Git提交代码的码农到如今的Git资深用户，期间你翻阅了很多文档，阅读了很多博文，经常泡在stackoverflow和githu上，学习了无数繁杂的内容。如果不是这些繁杂的内容，你遇到的很多问题没法解决。的确，就像“又不是不能跑”一样，能用就行。但是对于不同的人、同一个人的不同时期，“能用”也是一个变量。
