其实git的核心作用，底层作用是record your changes
如果不用git（包括类似的软件），开发者和系统管理员对于一个文件夹内文件和目录结构的改变，就只是改变了，改成什么样，这个目录内的情况就是什么样了，保存了就保持的是最新的状态。
如果用了git，明显可以帮助到开发者和系统管理员对于一个文件夹的管理的点是，能记录这个目录里面的更改历史，就是几月几号谁改了什么，当时提交这次更改的时候，备注的msg是什么。哦，所以git的核心作用是记录一个目录里面文件和子目录的改变历史。那为什么要记录这些呢。为什么需要记录这些呢。一般应该是，这个目录里面的数据经常改变的时候。那么什么样的情况下，一个目录里面的数据经常改变，而且还想记录下每次改变呢。这样就是开发者和系统管理员在做实验的时候，因为涉及到多次的测试，多次的修改。如果仅仅是改，也不用git，改了保存就好了，就和平时写一个文档差不多。但是涉及到设计和开发这一块，方案有很多个版本，可能一直改来改去，最后还是发现前面是，甚至就是第一版就是想要的效果。这个时候没有怎么回到前面的某个版本。怎么办？那个版本是什么时候修改的，当时是为什么改。能不能把这个目录内的状态直接回到那一次的状态，省的操作者一个个手动把目录内的所有内容改回去了，如果是涉及到多个文件多个代码，手动改回去的容错率低工作量大，简直是太麻烦了，而且考记忆去记的话，可能记不住。所以这个时候要实现这个时光倒流的情况，就可以用工具给平时的每一次修改做一个记录，就相当于拍个照做个截图，对于当时文件夹内的所有目录的结构和文件里面的数据，做一个完整的记录。物理的存在就是一个commit对应一个当时的目录和文件的tree树结构，tree树的底层是文件，文件的实际存储底层是blob，blob是具有原子性的，可复用的。所以一个tree结构加上底层的blob就可以组合成一个commit对应的当时的文件夹状态了。所以理论上，后面commit了多次之后，每个commit对应一个sha-1的hash值，然后切换到这个hash值，目录内的结果按照当时的tree结构和blob进行组织目录结构和文件名和blob与文件的对应关系，整个文件夹就里面的工作区就回到了当时这个commit的状态了。相当于一键还原。这个就解决了刚才的那个需求。所以git的主要作用就是记录修改历史，能够帮助使用者把文件夹的工作区轻松的回到某次之前修改的状态。
用户可以不用git，如果不需要记录一个文件夹内数据的修改记录的话。就像我们平时不做项目时，仅仅修改一两个文件里面的东西的话，改成什么样就什么样了，不用恢复到之前哪次修改的状态，或者需要的时候，大概也记得住，手动改回去也不麻烦。甚至写个小说也可以很随意的改，主要是一种感觉。但是如果像上学时候一样，写作文的话呢，写着写着，改来改去，删了重写，有时候状态好，有时候状态一般，就会导致改的不成样子了，后面可能想着，算了第一次第二次的修改就可以了，可以交作业了。但是没有记录修改历史，回到那个状态，就很难了。如果用了git，只要是在这个文件夹里面的文档里面写作文，第一次修改之后commit过，那么最后要回到这个状态就很简单了，git checkout commit_hash_numb就可以了。所以git的核心作用是记录修改历史，方便切换到某个时期的状态，当然也可以再切回来。用git管理自己的一个本地文件夹，其实完全可以不用github，就本地一个git就够了，用commit记录每次修改。
那么github是什么呢？就是一个网站。当你的这个文件夹里面写的东西，想让别人一起看，甚至别人也和你一起修改的时候，那你就需要和他通信，按照传统的方式，就是你改好，用传输工具发给他，他改了之后再发给你。这样发来发去，其实挺麻烦的，那么就可以你改了之后，把最新的修改结果放到网站上，他要改的时候，直接从网站上下载到他的电脑上去改。这样有一个中间的网站，你俩都把东西往这个网站服务器上放，就是解耦的工作了，你休息的时候不影响他修改，他休息的时候也不影响你修改。而且你和他不想一起把这个文件夹越改越乱的话，两个人想法不一样，或者这个文件夹里面的东西，你是主要的开发者，别人是开源的参与者，那么你就可以不让别人修改主分支，但是可以拉一个新分支出去，就是fork，他在上面随便改，甚至也可以删掉，但是不影响你主分支的修改，如果他改的想合并到你的主分支上，就可以发一个pull request，就是请求你拉他的修改，把他修改的东西和你的分支进行一个合并。你可以合并过来，也可以不合并过来。这就是分支的作用。如果就你一个人开发，你也可以不要分支，就只是找个地方存文件夹就行了，不管在哪个电脑上，只要给你的github账号配了这个新电脑的ssh公钥，就相当于你的github账号授权你这个电脑拉这里的代码了，包括推送。
所以，git，github，分支都不是必要的，包括tag，看你需不需要而已。TAG其实就是给某个分支上的某次commit起个外号，commit的hash值记不住，commit对应的msg能帮助找到某次修改是干嘛了，但是修改太多，也容易记不住，所以干脆给这个commit打一个TAG，说这次哪次重要的修改，比如是release1.2.5封板了。OK，这样就方便找了。当然，你也可以靠自己的记忆力去记，就是不打TAG，如果你愿意的话。但是那样太累有这功夫的话，不如搞点别的