我一直觉得，使用 Git 的时候把操作过程在脑海里视觉化会非常有用：当我执行某个命令的时候，分支之间是如何交互的？又是如何影响提交历史的？当我在master分支执行hard reset、force push到 origin、在.git文件夹执行rimraf的时候，为什么我的同事都哭了？
我认为创建一些最常见、最实用的命令的可视化示例是最佳使用指南！接下来介绍的这些命令，很多都有可选参数，用于改变命令的行为。文中的示例只讨论命令的默认行为，不会涉及太多的配置选项。这些命令包括 merge，rebase，reset， revert，cherry-pick，fetch，pull，reflog 等。
merge
多分支可以非常方便地将新的改动互相隔离，并确保你不会意外地将未经批准或破坏性的变更推到生产环境。一旦变更被批准，我们就能在生产分支中得到这些变更。
从一个分支获取变更到另一个分支的方式之一是执行git merge命令。Git 有两类合并操作：fast-forward 和no-fast-forward。
这么说你可能没什么概念，我们来看看区别吧。
fast-forward (--ff)
如果当前分支与即将合并过来的分支相比，没有额外的提交，这种就是fast-forward合并。Git 很会偷懒，它会首先尝试最简单的方案，即fast-forward。这种合并方式不会创建新的提交，只是把另一个分支的提交记录直接合并到当前分支。
没毛病！现在我们在master分支上有了dev分支上的所有变更。那么，no-fast-forward 又是什么呢？
no-fast-foward (--no-ff)
跟即将合并过来的分支比较，当前分支如果没有额外的提交，这固然很好，但实际情况往往不是这样！如果我们在当前分支上也提交了一些改动，那么 Git 就会执行no-fast-forward合并。
对于 no-fast-forward 合并，Git 会在当前分支上创建一个新的合并提交。该提交的父提交同时指向当前分支和合并过来的分支。
也没毛病！现在master分支上有了我们在dev分支上做的所有变更。
合并冲突
虽然 Git 擅长决定如何合并分支和更改文件，但它也不是总能自己做出决定。当我们试图合并的两个分支在同一文件的同一行上都有改动时，或者一个分支删除了文件，另一个分支又修改了它，都可能发生这种情况。
这种情况下，Git 会要求你帮助决定要保留哪边的改动。假设在两个分支上，我们都编辑了README.md文件的第一行：
如果把dev合并到master，会导致合并冲突：你是要 Hello!呢，还是要 Hey!？
合并分支时，Git 会显示冲突的位置。我们可以手动删除不想保留的改动，然后保存，再添加改动后的文件（git add）并提交。
大功告成！合并冲突虽然很烦人，但也是合理的：Git 不应该自作主张保留哪边的改动。
rebase
刚刚我们看到了如何通过执行git merge将一个分支的改动应用到另一个分支。另一种方式是使用git rebase。
git rebase 命令复制当前分支的提交，然后把这些提交放到指定分支之上。
现在master分支上的所有改动都跑到dev分支上了！
与merge相比，最大的区别是 Git 不会去找出哪些文件需要保留，哪些文件不需要保留。我们要rebase的分支总是包含了我们想要保留的最新改动。这种方式不会有合并冲突，并且保持了良好的线性 Git 历史记录。
这个例子演示了在 master分支上执行rebase。不过，在大项目里你可能不会这么做。 git rebase命令会修改项目历史记录，因为复制的提交会产生新的 hash。
当你在特性分支上开发时，master分支有更新的时候，rebase 很有用。这样你在当前分支就能拿到所有更新，避免了将来可能的合并冲突。
交互式 rebase
在 rebase 之前，我们还可以修改！这是通过交互式 rebase 实现的。交互式 rebase 也可以用于当前正在处理的分支，在希望修改某些提交的时候。
对于即将 rebase 的提交，可以执行 6 种操作：
reword：修改提交说明edit：修改提交内容（amend）squash：将该提交合并到前一个提交fixup: 将该提交合并到前一个提交，不保留提交的日志消息exec: 在想要 rebase 的每一个提交上执行命令drop: 删除提交
666！这样，我们就能完全控制提交记录了。如果想删除某个提交，只要 drop它就行了。
或者，如果我们想要把多个提交合并到一起，这样历史记录会更清晰，也没问题！
交互式 rebase 给了你对想要 rebase 的提交很多控制权，哪怕是当前的活动分支。
reset
有时候我们提交了一些改动，后来又不想要了。有可能是WIP提交，也可能是某个引入了 bug 的提交。这种情况，我们可以执行git reset。
git reset会丢弃当前所有暂存的文件，并让我们决定 HEAD 应该指向哪里。
soft reset
soft reset 将HEAD 移动到指定的提交（或者相对于HEAD 的位置索引），同时不会丢弃这些提交带来的改动。
假设我们不想保留添加了style.css文件的提交9e78i，也不想保留添加了index.js文件的提交035cc 。但是，我们却想要保留新增的style.css和index.js 文件。这里用 soft reset 就非常合适。
执行git status，你会看到我们依然能够查看之前提交所做的改动。这很有用，因为这样我们就能继续修改文件内容，后续再次提交了。
hard reset
有时候，我们不想保留某些提交带来的改动。跟 soft reset 不一样，我们不再需要访问这些变动了。Git 应该简单地重置到指定的提交，并且会重置工作区和暂存区的文件。
Git 已经丢弃了9e78i 和 035cc 两个提交引起的改动，并把状态重置到了提交ec5be的位置。
revert
撤销改动的另一种方式是执行git revert。复原某个提交后，会创建一个新的提交，包含了恢复后的改动。
假设提交 ec5be添加了一个index.js文件。随后，我们发现实际上不再需要这个改动了，就可以恢复ec5be这个提交。
提交9e78i恢复了ec5be 这个提交带来的改动。执行 git revert对于撤销某个提交非常有用，同时又不会修改分支的历史。
cherry-pick
当活动分支需要某个分支的某个提交包含的改动时，我们可以用cherry-pick命令。通过cherry-pick某个提交，在当前活动分支上会创建一个新提交，包含了前者带来的改动。
假设 dev 分支上的提交76d12改动了index.js文件，我们在master分支上也需要。我们不需要整个分支上的改动，只要这个提交。
666，master分支现在也包含了76d12提交的改动了。
fetch
如果存在远程分支，远程分支可能有些提交是当前的本地分支没有的。有可能是其他分支合并过去了，或者你的同事推送了某些改动，等等。
我们可以用 git fetch 把这些改动获取到本地。这不会影响本地分支，fetch只是下载数据。
现在就可以看到从最近一次推送以来的所有变动。本地有了这些新数据，我们就可以决定如何使用了。
pull
除了用git fetch 获取远程分支信息外，还可以用git pull。git pull实际上是两个命令合而为一：git fetch和git merge。当我们从 origin 拉取改动时，先是像git fetch一样获取所有数据，然后最新改动会自动合并到本地分支。
这样就跟远程分支保持同步了，包含了所有的最新改动。
reflog
每个人都会犯错误，这完全没有关系！有时候你可能觉得自己把仓库搞得一团糟，只想把它删了完事。
git reflog是个非常有用的命令，可以显示所有操作的日志。包括 merge，reset，revert 等，基本上包括了对分支的任何更改。
如果出错了，你可以根据reflog提供的信息通过重置HEAD 来撤销改动。
比如，我们实际上并不想合并分支。当我们执行 git reflog命令时，我们看到在合并前仓库位于 HEAD@{1}。我们执行下git reset命令，让 HEAD 重新指回原来的HEAD@{1}位置。
我们可以看到，最新的操作也记录到reflog里了。
总结
Git 还有很多有用的命令，篇幅所限不能一一列举。希望通过上面这些形象的动画演示，你能够更好地理解这些分支操作。
原文：CS Visualized: Useful Git Commands
翻译：李中凯
