在上一章的Github起手式中，我们简要的介绍了一下什么是Github，以及如何注册账号与配置Github，现在我们将进一步介绍Github。
github已经是一个非常流行的程序仓储和版本控制解决方案了，唯一不足的就是如果是私有云存储的话，还是需要付费使用，不过这也是在情理之中，毕竟中国的网盘全部都挂了（VS天天推销它的免费云存储，有兴趣的可以去那看看）。
github的执行方式有命令行的形式，最近也出了一个图形化界面，当然不是自带的那个简陋的GUI，而是一个真正的for windows,具体界面如下图所示：
因此这样就非常方便我们对于仓库的管理了，至少可以减少很多命令行。但是如果真的要了解github的话，还是建议从命令行开始学起。
这是两个非常重要的部分（至少人家是这样讲的）。
众所周知，window,Linux和Mac使用的行尾是不同的，也就是换行符不同。UNIX/Linux 使用的是 0x0A（LF），早期的 Mac OS 使用的是0x0D（CR），后来的 OS X 在更换内核后与 UNIX 保持一致了。但 DOS/Windows 一直使用 0x0D0A（CRLF）作为换行符。
那么github为我们提供了一个换行符自动转换功能，虽然github推荐只将 UNIX 风格的换行符保存入库,但它也考虑到跨平台协作的场景，并且提供了一个“换行符自动转换”功能。
这个功能默认处于“自动模式”，当你在签出文件时，它试图将 UNIX 换行符（LF）替换为 Windows 的换行符（CRLF）；当你在提交文件时，它又试图将 CRLF 替换为 LF。
命令行的设置如下：
git config --global core.autocrlf true这样就把自动转换功能开启了。但这对于中文来讲是有bug的，因为如果你手头的这个文件是一个包含中文字符的 UTF-8 文件，那么这个“换行符自动转换”功能 在提交时是不工作的（但签出时的转换处理没有问题）。
因为你提交到仓库的文件已经完全变成了 Windows 风格（签出时把 UNIX 风格转成了 Windows 风格但提交时并没有转换），每一行都有修改（参见本文开头的示意图），而这个修改又不可见（大多数 diff 工具很难清楚地显示出换行符），这最终导致谁也看不出你这次提交到底修改了什么。
这还没完。如果其他小伙伴发现了这个问题、又好心地把换行符改了回来，然后你又再次重演上面的悲剧，那么这个文件的编辑历史基本上就成为一个谜团了
这样看来我们还是把这个功能关闭吧，改成更保守的形式吧：
$ git config --global core.autocrlf false
$ git config --global core.safecrlf true这样，第二步的作用是换行符检查功能（core.safecrlf），可以在提交时检查文件是否混用了不同风格的换行符。这个功能的选项如下：
false – 不做任何检查
warn – 在提交时检查并警告
true – 在提交时检查，如果发现混用则拒绝提交
这样就能保证万无一失了。
3.2 命令行的颜色
这里的内容不是太重要，基本上就是以下几种：
- 如果命令行是红色，表示仍在处理
- 如果命令行是绿色，表示运行正常
- 如果是橘黄色，则表示这是分支
- 如果是黄色，则表示是历史纪录
另外，在设置的级别中，也分为3级，分别是本地级，全局级和系统级。其优先级恰恰相反，本地级最高，全局级次之，系统级最低。也就是说，本地级的命令可以覆盖全局级的命令，全局级的命令可以覆盖系统级的。那这个在哪体现呢？看一下这个代码：
$ git config --global color.ui auto可以清楚的看到--global的踪迹。
4. 小结
好了我们今天就讲到这里，下期我们讲开始讲解创建一个仓库等内容。
