技术的乐趣就在于解决一个个问题的过程中！

有一个问题纠缠我好久，一直没找到问题的原因。
在github上创建了个仓库，在本地上传总是失败。

cd bingo
git init
git add .
git commmit -m 'first commit'
git push -u origin master  // 99%

git push后，经过好长时间，进度条一直卡在99%，就是无法100%。
开始我以为是网络原因，然而自动代理模式、全局模式都试过了，还是无法成功。
这个问题一度让我很是崩溃，今天再次尝试还是失败。
见了鬼了，我这翻墙代理很给力啊，不可能是网络原因啊。
后来我看了下这个文件夹大小，108MB，把我吓一跳，怎么可能这么大。
我仔细查看了目录下的各个文件，都很小，最大也就是十几K，难道是node_modules目录依赖太多吗？
我删除了node_modules目录，容量变成98MB，还是很恐怖。
命令行下执行：
ls -al(默认是没有容量单位显示的)
ls -alh(默认是以B(字节)\KB等来显示的)
还是没看出到底是哪个文件如此之大。
真是让我头疼死了，死活找不到到底是哪个文件如此之大。
后来回想起我操作Windows电脑的习惯，打开隐藏文件，在文件夹属性设置一下即可。
但是Mac居然不支持图形操作，从网上得知可以命令开启：
defaults write com.apple.finder AppleShowAllFiles -bool true
终于打开了隐藏文件，然后在文件夹逐个查看文件体积，发现.git文件占据了96MB。
瞬间明白为什么总是卡在99%了？
.git目录下有数量非常多的细小文件，所以命令行就会显示一直在上传。
这里涉及一个常识：并不是文件越大上传越慢，速度快慢不仅取决于网络、容量，还取决于文件结构。

果断删除.git，重新git init。
然后查看文件夹，容量为2MB，终于正常，最后上传代码成功。
问题解决后我想起之前我查看过目录大小，为何没有发现呢？
仔细尝试这个命令，发现ls -alh命令显示目录大小是失效的。
如果是文件，显示的大小是正确的。
但如果是目录，它显示的是当前目录的大小，并不包含里面的目录或文件。
不得不说这是Unix Shell设计上的一个小bug，这很容易误导人。
我又开始想了，难道Unix就没有设计一个显示目录文件大小的命令吗？
网上搜索后得知了：du -h 以人机可读的方式列出当前目录的所有层级内容。
也就是这个命令才可以正确地获知一个目录的大小，而通过ls -alh是做不到的。
通过这件事对Unix命令也算有了更深的认识，所有的付出终归是值得的。
learn by doing，如果不是自己切身的体会，恐怕永远是弄不明白Unix命令之间的差异的。
当然了，这个问题的最简单解决方案就是在根目录下添加.gitignore文件，并配置上.git目录。
这样上传代码的时候就自动忽略了不必要的目录。

这件事情给我的触动很大，一方面自己的命令行知识还需要加强，另一方面，.gitignore也很重要。