我们经常会使用git进行项目版本管理，但是你真的了解每条指令都在做什么吗？本文就带你看看每条指令的作用吧~
最初状态
我们约定一下，最初只有一条提交记录的状态，如图：
本地仓库最初状态
git commit
新建1次提交
git commit
git branch Tom
git学习.png
git checkout Tom
git学习.png
master和Tom各自提交一次
git学习.png
git merge Tom
git学习.png
git checkout Tom; git merge master
git学习.png
git rebase Tom
我们回到master 和 Tom分支合并前的状态，并执行上述指令
git学习.png
git checkout Tom； git rebase master
master继承自Tom，故只需移动Tom指针
git学习.png
git checkout C3
此处假设 C0，C1，C2，C3，C4,C5均是提交记录的哈希值
git学习.png
git branch -f master HEAD^
^是HEAD指针上一个提交记录
~n是HEAD指针上n个提交记录
^n是HEAD指针的第n个双亲节点
git学习.png
从HEAD分离回到正常状态--git checkout Tom
git学习.png
撤销提交之git reset HEAD^
git学习.png
撤销变更之 git revert HEAD^
C2和C2''内容保持一致
git学习.png
整理提交记录 git cherry-pick
依次执行以下指令，将所有提交按顺序放入master分支中
git checkout master;
git cherry-pick C2 C3 C4
此处依旧约定C1 C2 C3 C4为提交记录的哈希值
git学习.png
git tag
我们再像看连环画一样地快速看一眼上述的配图，是不是发现了什么？虽然分支可以移来移去的，但是提交记录的位置是不会变动的，我们可以使用git tag对这些提交记录打标签
执行 git tag version-2.0 HEAD~2
git学习.png
git tag的意义？
tag是commit id的一个引用，因此 可以使用 git checkout version-2.0 替代冗长的 git checkout 0x12hg13cgh213v321
git学习.png
题外话
分离出HEAD指针是非常危险的，在分离头指针的状态下，一般正经的终端都会给出明显的提示，如果在回到master（其它分支一样）前没有对提交进行合并或者打tag，那么之前的修改提交基本都会丢失。
执行 git commit
git学习.png
执行 git checkout master
git学习.png
如果你真的学会了我之前所讲的内容，你会很容易的发现哈希值为C5的提交记录已经是一个孤立的节点了（中间的C3也是），是无法被追踪到的，因此这次修改提交是徒劳的。
警惕以下情况！！！
git checkout C4
（此处仍约定C4为该次提交记录的哈希值）
git学习.png
可以看看这位小哥遇到过的坑 传送门点我
本文完
网友评论