【Git】 理解Git之命令篇 终于把这篇文章发表出来了...

一直以来要写一篇关于git命令使用的文章，最近终于挤出来时间把常用的命令汇总一下方便自己和同学们查考，阅读本文需要同学们有点git使用基础。网上入门教程很多可以稍做了解，楼主很不赞成开发者开始就使用可视化界面去操作平时的代码管理。因为如果开发团队人数少的话还可以，人数几十上百个的话，如果开发对于git的原理不熟悉就很容易导致项目管理的混乱。

概念

git 最让人迷惑的就是一些概念名称，我把这些不太容易理解或者混淆的单独拎出来做下回顾。

工作区 暂存区 仓库

在初始化git版本库之后会生成一个隐藏的文件 .git ，可以将该文件理解为git的版本库 repository，而我们自己建立的项目文件夹即工作区 working directory ,在.git 文件夹里面还有很多文件，其中有一个index 文件 就是暂存区也可以叫做 stage ,git还为我们自动生成了一个分支master以及指向该分支的指针head ，可以看到版本库里维护了暂存区和分支两大部分。当然分支可以有很多个

工作区: 一般是我们项目的目录
暂存区： 本地项目如果有内容修改后 通过git add 命令就把工作区的修改记录同步到了暂存区（使用git checkout 命令把暂存区域的修改撤销，会在撤销相关进行详细描述）
分支： 当我们在某个分支上进行commit 操作就把当前暂存区的 （通过git reset 把提交到分支的commit 记录撤销到暂存区。会在撤销相关进行详细描述）
下面的内容我们就会围绕这几个区域进行详细的说明

HEAD ,HEAD^ , HEAD~

https://blog.csdn.net/fly_zxy/article/details/82593842
参考-选择修订版本

HEAD: 可以理解为我们每次提交的commit都为一个指针，HEAD即为指向当前分支最后一次提交的一个指针
HEAD^ : 在HEAD的基础上的父提交，如果^n n为数字（查看当前comitid的第n次父提交的内容）
HEAD~:当前HEAD基础上的上一次提交内容（区别于^）, ~n 为往上数第n次提交记录

合并使用HEAD~3^2 ：当前分支最新提交的前三次提交的第二个父提交的指针。

容易引起迷惑的一些点

分支合并（git rebase,git merge）

git 分支合并原则 尽可能保留分支的操作过程，也就是分支信息和commit提交信息
参考

git rebase:使用原则： 对于不再有子分支的branch，并且因为rebase而会被重写的commits都还没有push分享过，可以比较安全地做rebase，如果满足上面的条件则非常建议使用git rebase

git cherry-pick <commit id> git rebase 针对的是分支，此命令针对的是特定的commit id 使用场景可按照rebase的原则来

git merge : 按照合并的原则是尽可能保存commit的分支以及提交记录，–no-ff比较常用
--no-ff 指的是强行关闭fast-forward方式，不使用fast-forward方式合并，保留分支的commit历史
--squash 是用来把一些不必要commit进行压缩，比如说，你的feature在开发的时候写的commit很乱，那么我们合并的时候不希望把这些历史commit带过来，于是使用–squash进行合并
--no-commit 直接不产生新的commit直接合并

错误案例:

下面展示了已经在中央库存在的feature分支，两个开发人员Bob和Anna做了对feature分支针对master做rebase操作后，再次push并且同步工作带来的灾难：历史混乱，并且merge后存在多个完全相同的changeset。

也就是说，Master 这个分支是一个共享分支，多个开发人员都在其上有提交的commit，如果对rebase Master到自己的分支然后再次提交的自己的feture就会造成如上的一些混乱的历史。

正确范例：

假如有两个分支并行开发 一个叫Feture 一个叫 John/Feture

git 合并一个独立的分支到自己的私有分支上。

如上图展示了 git rebase Feature 到 John/Feature ，虽然 rebase和merge 都能达到效果，但是如上的rebase 更清爽一些。

可以总结为：git rebase 后面的分支名一定不要是多人共享的分支，可以是本地的私有分支，可以是仓库里独立开发的分支

撤销 （git reset ,git revert, git reflog）

常用的两个撤销相关的命令git reset和git checkout

git resest --hard commitid 比较危险直接把选中的commitid作为当前分支的HEAD，并且清空暂存区。合理使用

git reset --soft commitid 把commitid之前的恢复到暂存区。注意这个commit是需要回退的commit的前一个commit

git revert commitid 把commitid 回退到当前的版本库,和git reset --hard的区别是HEAD 指针继续向前，而不是直接退回到某个commit并且删除记录。revert 后会在原有提交记录的基础上新增一条记录但是内容会返回到commitid对应的提交内容。

git reflog 分支被删除或者git reset --hard 删除了一些提交记录后 也可以通过此命令查看一些提交的记录。