看教程，听老师讲，自己也一边练习，碰到问题，然后再查询，询问，有时候，问题莫名其妙得到了处理了，刚开始不太明了的感，只能死记硬背，毕竟出错的源头太多了，很快会晕，时间长了，碰到的问题和解决问题多了，心中就会趋向于规范化git本身的认知，建立体系，由此也会明白以后什么时候用，用什么命令好了。我不想讲一些教程，因为无所谓了，太多了，而且命令操作表象就是靠自己手动实践才能掌握的。我只是说些自己的感官想法。

</p>

逻辑性

---

有在git环境下的一些基本的命令，创建啊，删除啊，修改啊，标记啊，保存到暂存区啊，到后来的关联到远程库的相关指令啊，还有对库本身的操作啊，仅仅是特定某次针对于另一个库的操作，或者后来的分支构建，，，

<p>
命令多倒不多，但也不少，而且有很多命令可以重复使用，可以用在某一情况，然后其他情况，你发现也可以，而有时候却没效果，让我敲命令时心里忐忑，自己都是以质疑的态度想整个运行命令的结果的。
这是为什么？为什么这个命令可以这么用？开发git的已经把软件设定好了，应对你要完成的目的，得出需要执行的命令。所以比较有目的性的命令最容易掌握，最符合我的逻辑的，我想要切换dev分支就输入

git checkout dev

我想推送远程库origin master就是

git push origin master

没啥疑惑的。
我自己有疑惑的是分区逻辑，因为有这个分区逻辑，我觉得所有的命令才是有效的。
比如说，本地库修改个文件，这文件只是改到文件本身上了，暂存区这个逻辑区没有变动啊，所以用

git status

查一下啊，能查到实体文件，跟暂存区这个逻辑镜像里的不同，然后就提示你了，需要更新暂存区。这是个逻辑啊，对应的一系列命令就很有意义了，有目的性啦。
新文件跟暂存区要跟踪关联吧，所以

git add .

但是本地库这个逻辑分区没有变动啊，为什么我们还要变动了？因为这几个逻辑分区有互相的关系链，虽然是平级，但是不能越过中间的区直接与下一个区产生命令操作的。你想要把更新推送到远程库，必须要从本地库去推送的。反过来，也很有意思，远程库修改后推送到本地，也就是用pull的命令时，只能直接推送到本地库，这就是逻辑。
<p>

在我看来，暂存区相当于文件实体与本地库的一个对接，相对于本地库而言，具有的功能就是时刻对比文件，提示更新库，还有就是一个类似于端口一样，使二者产生联系，并能触发各种命令的。
当时听老师讲的时候，我有个疑问，在git环境下删除的文件，是删除的实体文件没错，然后暂存区那里会如何？本地库呢？又因为我发现了文件本身变的时候，本地库不变，因为需要我们用commit命令的原因，而本地库变的时候，文件会变，因为pull命令的效果。所以删除文件，我具体操作了一下

删除文件命令

实际上的意思应该就是，暂存区需要跟踪，我也不知道说更新这个词合不合适了，本地库需要更新了。所以这个逻辑就是实体文件变动了，暂存区有能力察觉出来，然后告诉你更新本地库了。在这里，我对暂存区这个逻辑区有个猜测，应该是本地库一体的，只不过为了逻辑性，弄出来一个逻辑分区，好像电脑磁盘里的各个分区一样的感了。真正的本地库其实也是一个逻辑上的分区概念了，只是为了让命令变得有意义，操作有依据了。
至于后面的大家纠结的两个大兄弟：

git commit -am                    git commit -m

老师给的区别是am的命令可以用在不新建的改动上，m的用在所有的上面，不过刚才新建的情况下用，也能更新到本地库，所以具体是什么参数区别，就暂时没明白，不过可以用就好， 带m 的是万金油，其实参数区都是单词缩写的，可以从这上面参考，不过输入命令

git commit -am

然后直接回车，得到commit的一系列，我截图了，然后大家参考下，我是没有找到什么突破的：

基本是这个感觉了。
</p>

还有个比较有趣的发现，如果我在本地库新建一个文件夹，空的，然后暂存区就没有检测功能了，再怎么运行commit命令也是没办法，推到远程库也是不显示，除非里面有文件，有了文件就能检测到，上传了，远程库也有了，其实这跟远程库没多大关系，上面说了远程库只跟本地库联系，所以还是本地库的意思，空文件夹不被暂存区识别喽？我记得刚接触命令的时候，看到过介绍，变动只是提示到你字节之类内存之类的变动，具体主动性的还是要看键盘手的注释了，所以我觉得暂存区的跟踪发挥能力，应该是里面的镜像对比各个路径下的字节变动吗？