Git常用命令

1. 状态

1.1 文件状态

2. 分支

2.1 分支常用命令

git branch xxx：新建分支
git checkout xxx：切换分支
git checkout -b xxx：新建分支并切换到该分支（相当于上面两条命令）
git branch -d xxx：删除分支
git branch：查看分支列表
git push origin --delete xxx：删除远程分支
git fetch：从服务器上拉取数据，当 git fetch 命令从服务器上抓取本地没有的数据时，它并不会修改工作目录中的数据，它只会获取数据然后让你自己合并。
git pull：在大多数情况下它的含义是一个 git fetch 紧接着一个 git merge / git rebase 命令

2.2 分支合并

分支合并主要有两种方式：git merge / git rebase

2.2.1 git merge

git merge 会把两个分支的最新快照以及二者最近的公共祖先进行三方合并，合并的结果是生成一个新的快照（并提交）

工作中的使用流程

现有主分支 master，开发某种功能的分支 dev，dev 上面的内容已经开发完成了，现在要将 dev 分支上的内容合并到 master

git checkout master
git pull（拉取最新代码，也可以使用 git fetch）
git merge dev
… （解决冲突）
git push （提交到服务器）

2.2.2 git rebase

现在同样有主分支 master 与开发分支 dev，需要将 dev 合并到 master

git rebase 的原理是先找到两个分支（master 与 dev）的最近公共祖先，然后对比 dev 分支对于该祖先的历次提交，提取相应的修改并存为临时文件，然后将当前分支指向目标分支（master）的最新一次的提交，最后将之前另存为临时文件的修改依序应用

工作中的使用流程

git checkout master（切换到目标分支）
git pull （拉取最新代码）（也可以直接执行 git rebase master dev，省去步骤3和步骤4 ）
git checkout dev （切换到开发分支）
git rebase master （执行变基操作）
git checkout master （切换到主分支）
git merge dev （将 dev 分支上的修改变基到主分支）
git push （提交到服务器）

变基操作前的分支图

变基完成后的分支图

无论是 rebase 还是 merge ，整合的最终结果所指向的快照始终是一样的，只不过提交的历史不同罢了。变基是将一系列提交按照原有次序依次应用到另一分支上，而合并是把最终结果合在一起

3. 常用命令

3.1 汇总

git add -i：进入交互式终端模式，可以快速选择某些文件被暂存，达成部分提交的目的。另外该模式下还有多种快捷功能。

git commit --amend：修改最近一次提交的提交信息

git rebase -i：交互式的运行变基，修改多个提交信息（注意无论是 git commit --amend 还是 git rebase -i 都不能涉及到已经推送到服务器的提交）

git revert：撤销（还原）某次提交

3.2 git reset 的不同模式

3.2.1 git reset --soft HEAD~

首先要明白 git 的 “三棵树”，HEAD、Index 以及 Working Directory。

HEAD 是指已经 commit 快照，可以将它看做是 该分支上的最后一次提交；

Index 是 “暂存区”，是预期的下一次提交；

Working Directory 是我们自己的工作目录；

我们在工作目录中对文件进行修改，然后添加到暂存区，最后再 commit，HEAD 指向我们最后一次的 commit。

我们运行 git reset --soft HEAD~ 会产生什么效果？下图是我们现在的分支状态和 “三棵树” 的状态

然后我们运行 git reset --soft HEAD~

可以看到，Index 区和 Working Directory 区的状态并没有发生变化，只有 HEAD 指针向前移动了一个节点，git reset --soft HEAD~ 的本质上是撤销了上一次 git commit 命令。当我们运行 git commit 时，Git 会创建一个新的提交，并移动 HEAD 所指向的分支来使其指向该提交，当将它 reset 回 HEAD~（HEAD 的父结点）时，其实就是把该分支移动回原来的位置，而不会改变 Index 和 Work Directory。现在可以再次运行 git commit 以达到和 git commit --amend 相同的效果。

解释

git reset --soft HEAD~命令会把Git的HEAD指针移动到前一个提交，但是它不会改变索引(index)和工作目录。这就意味着所有的文件改动会被保留，就像你刚刚执行了git add .命令一样。

这里有一个简单的例子来帮助你理解：

你修改了一些文件。
你运行git add .命令，把这些改动添加到Git的索引中。
你运行git commit -m "your message"命令，提交这些改动。

现在，如果你运行git reset --soft HEAD~命令，Git会回退到第2步，也就是说，所有的文件改动都还在，就像你刚刚执行了git add .命令一样。

这个命令在你想要修改最后一次提交的时候非常有用。例如，如果你发现你在最后一次提交的信息中犯了一个错，或者你忘记添加一些文件，你可以使用git reset --soft HEAD~命令回退到git add .，然后再进行提交。

3.2.2 git reset [–mixed] HEAD~

mixed 是 git reset 操作的默认参数，git reset --mixed HEAD~ 可以重置 Index （暂存区）的文件与上次的 commit 保持一致，Work Directory 的内容保持不变。

当我们运行 git reset --mixed HEAD~ 时，reset 会用 HEAD 指向的当前快照的内容来更新索引

git reset --mixed HEAD~ 操作共有两个步骤

将 HEAD 指针向前移动一个节点，也就是 git reset --soft HEAD~ 操作
重置 Index （暂存区）的文件与 HEAD 指向的节点保持一致

3.2.3 git reset --hard HEAD~

–hard 是 reset 命令唯一的危险用法，git reset --hard HEAD~ 命令会撤销最后的提交、git add 和 git commit 命令以及 Work Directory 中所有的工作

git reset --hard HEAD~ 总共有三个步骤

将 HEAD 指针向前移一个节点，也就是 git reset --soft HEAD~ 操作
重置 Index （暂存区）的文件与 HEAD 指向的节点保持一致，也就是 git reset --mixed HEAD~ 操作
重置 Work Directory 的文件与 HEAD 和 Index 保持一致

丢失掉最后一次提交。

3.2.4 git reset 的其他用法

git reset file.txt（其实是 git reset --mixed HEAD file.txt 的简写形式），它的实质是将 file.txt 从 HEAD 复制到 Index ，该命令总共有两个步骤：

移动 HEAD 分支的指向（因为我们给 reset 指定了一个路径，所以它的作用范围限定为指定的文件或文件集合，而 HEAD 只是一个指针，无法让它指向两个提交中各自的一部分，所以该步骤会跳过，HEAD 的指向不变）
让 Index 看起来像 HEAD

因为 git reset file.txt 会产生 Index 与 HEAD 中 file.txt 文件一模一样的结果，所以 file.txt 会从 Index （暂存区）被移除，git reset file.txt 与 git add file.txt 所做的事正好相反，所以我们可以使用 git reset file_name 来取消暂存一个文件。

我们也可以通过指针一个具体的提交来拉取对应的文件版本，类似于 git reset eb43bf file.txt，这时候再运行 git commit，就会将该版本的 file.txt 提交。