Git也用了挺久的了，很多常用命令用的比较熟了，但是具体原理还是讲不清除！现在尝试一步步梳理一下。
因为平时用的的是VSCode进行开发，所以也顺带尝试下VSCode自带的一些Git操作的快捷方式。
一个完成的操作流程
首先我们先快速看一下我们一整套开发流程走下来应该是怎样的：
- git checkout -b xiaozui/docs_git_workflow
- git tag xiaozui/docs_git_workflow_tag
- git push -u origin xiaozui/docs_git_workflow
- git add -A
- git commit -m ‘your commit msg’
- git push
上面简单描述了一个简化的开发时我们的操作流程，这里我们来分析一下我们的*HEAD指向问题。
什么是HEAD
A head is simply a reference to a commit object. Each head has a name. By default, there is a head in every repository called master. A repository can contain any number of heads. At any given time, one head is selected as the “current head.” This head is aliased to HEAD, always in capitals.
Note this difference: a “head” (lowercase) refers to any one of the named heads in the repository; “HEAD” (uppercase) refers exclusively to the currently active head. This distinction is used frequently in Git documentation. I also use the convention that names of heads, including HEAD, are set in italics.
上面两段是是对于HEAD的一个解释，网址传送门
主要的意思就是每个版本库中会有很多个head“指针”，但是HEAD指的是当前被选中的指针，也就是我们当前所在的分支。它指向的是一个具体的提交点，每当我们创建了一个新的提交点时，HEAD的指向就是进行更新，当然我们开发中也经常改动HEAD的指向。
cat .git/HEAD
我们在项目终端中输入上述命令我们能看到：
我当前所在的是上面创建的xiaozui/docs_git_workflow分支，如果切回主分支，显示的就是：
ref: refs/heads/master
PS: 关于.git后续会详细介绍。
第一步检出分支时做了哪些事
之前提到过
git checkout -b xiaozui/docs_git_workflow
是分成了两步走的：
- git branch xiaozui/docs_git_workflow
这步创建了一个新的分支xiaozui/docs_git_workflow，但是我们依旧停留在主分支。
- git checkout xiaozui/docs_git_workflow
这一步就是将HEAD切换到了我们新建的分支上了，这也就是我们切分支时实际上发生的事情。
打标签/补打标签
以前在变基的时候最痛苦的问题就是找第一个提交点，如果开发时间长提交点又多，那将是一件很麻烦的事。所以我们在检查分支时最好立马给它打上一个tag：
git tag xiaozui/docs_git_workflow_tag
这时打上的标签指向的就是我们刚检出项目时对应的那个节点：
这样一来我们就记录了我们从当前分支最开始的状态，我们运行命令：
git show xiaozui/docs_git_workflow_tag
我们可以发现
当然一开始没养成习惯的话，很容易就会忘了这件事，在提交了几次之后想起来没标签，我们可以补打标签：
git tag xiaozui/docs_git_workflow_tag [SHA-1]
我们只需要加上我们想打标签的界面commitid值就可以了。
当然我们打的这些标签只是为了我们在变基时方便查找起始点，它本身并没有什么特别的意义，所以我们本地的这种tag是不应该提交到远端的。
这是Vue的tag页面，我们可以看到tag是一个静态的节点，它往往标记着某一个比较重要的点。所以之钱在
Git commit编写指南那篇文章里我也有提到说后续小组可以考虑每次新功能发版时可以在这里做详细记录。
如果我们开发好某个功能合并到主分支后，我们可以通过：
git tag [tag_name] -a
这条命令来创建标签记录当前开发完且要发布的节点，终端会弹出信息输入界面让我们输入此标签的描述信息。这样的一个tag我们要推远端的话，运行以下命令：
git push origin [tag_name]
这样就将你的标签推送到远端了，我们能在gitlab上对应项目下Tags中看到我们的标签信息。
与远端仓库关联
我们平时在用VSCode开发检出一个新项目时，我们会发现右下角有这样一个图标：
这个图标说明我们当前分支还没推到远端，我们点击这个地方它就会将当前分支推到远端。
git push -u origin xiaozui/docs_git_workflow
这条命令在Git 变基指南分析过，这里就不再说了，现在要引入另一张图，为之后做准备。
我们可以看到origin/master这个指针，我们每次新建分支的时候都会更新主分支最新的代码，因此在当前状态我们和远端master指向的都是同一个提交点。但在后面的开发中会出现很多情况，跟这个指向就有很大关系了。
代码的暂存和提交
进入开发的阶段了，我们在本地开发时通常为以下几种状态：
比如这是一个我的某个时间点的工作区：
我们可以看到在暂存的更改和更改中都有launch.json这个文件，它显示的是未跟踪的状态。为什么会在工作区中同时出现呢？因为前面一张图已经表明，暂存区属于版本控制的一部分，它是由.git/index这个指针指向的，当你将某个文件的添加到暂存区之后，你之后的修改就属于一个新的修改，需要重新添加到缓冲区。
.git/index: 这指向是的暂存区，里面的内容可能是我们下一次的提交。每次我们检出一个分支时Git将工作目录的文件填充到我们的暂存区，然后我们工作中修改了文件，通过
git add来将修改移入暂存区。
前面那个删除的文件，是在实际开发中遇到了一个情况就是有些配置文件不需要同步的情况，但是我们第一次不小心又同步了。比如我不小心同步了.vscode下的文件：
git rm --cached .vscode/*
通过这条语句我们能够删除文件的跟踪状态，不会删除物理文件。这个在本机很OK，但是在推到远端时它就将那个文件直接删除了，所以下次其他人更新时这个文件会被删除。关于这个问题在segmentfault上有一个讨论大家可以看一下。
当我们进行了多次暂存提交之后，我们本地版本将领先远端分支几次提交，这时我们可能需要同步一下远端：
git push
后续我不再标出HEAD，因为分支不像标签是固定的，它会跟随着每次提交来进行更新，和HEAD保持一致（如果是当前分支的话）。
这张图在后面的变基中将会用到。