原文：https://dev.to/lydiahallie/cs-visualized-useful-git-commands-37p1
翻译整理：大道至简
虽然 Git 是一个强大的工具，但是我觉得大部分人都会同意我说的：它也可以是一个……噩梦！我一直觉得，使用 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。这种合并方式不会创建新的提交，只是把另一个分支的提交记录直接合并到当前分支。
fast-forward merge
没毛病！现在我们在master分支上有了dev分支上的所有变更。那么，no-fast-forward 又是什么呢？
no-fast-foward (--no-ff)
跟即将合并过来的分支比较，当前分支如果没有额外的提交，这固然很好，但实际情况往往不是这样！如果我们在当前分支上也提交了一些改动，那么 Git 就会执行no-fast-forward合并。
对于 no-fast-forward 合并，Git 会在当前分支上创建一个新的合并提交。该提交的父提交同时指向当前分支和合并过来的分支。
no-fast-forward
也没毛病！现在master分支上有了我们在dev分支上做的所有变更。
合并冲突
虽然 Git 擅长决定如何合并分支和更改文件，但它也不是总能自己做出决定。当我们试图合并的两个分支在同一文件的同一行上都有改动时，或者一个分支删除了文件，另一个分支又修改了它，都可能发生这种情况。
这种情况下，Git 会要求你帮助决定要保留哪边的改动。假设在两个分支上，我们都编辑了README.md文件的第一行：
如果把dev合并到master，会导致合并冲突：你是要 Hello!呢，还是要 Hey!？
合并分支时，Git 会显示冲突的位置。我们可以手动删除不想保留的改动，然后保存，再添加改动后的文件（git add）并提交。
合并冲突
大功告成！合并冲突虽然很烦人，但也是合理的：Git 不应该自作主张保留哪边的改动。
rebase
刚刚我们看到了如何通过执行git merge将一个分支的改动应用到另一个分支。另一种方式是使用git rebase。
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它就行了。
Alt Text
或者，如果我们想要把多个提交合并到一起，这样历史记录会更清晰，也没问题！
交互式 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 就非常合适。
image
执行git status，你会看到我们依然能够查看之前提交所做的改动。这很有用，因为这样我们就能继续修改文件内容，后续再次提交了。
hard reset
有时候，我们不想保留某些提交带来的改动。跟 soft reset 不一样，我们不再需要访问这些变动了。Git 应该简单地重置到指定的提交，并且会重置工作区和暂存区的文件。
Alt Text
Git 已经丢弃了9e78i 和 035cc 两个提交引起的改动，并把状态重置到了提交ec5be的位置。
revert
撤销改动的另一种方式是执行git revert。复原某个提交后，会创建一个新的提交，包含了恢复后的改动。
假设提交 ec5be添加了一个index.js文件。随后，我们发现实际上不再需要这个改动了，就可以恢复ec5be这个提交。
Alt Text
提交9e78i恢复了ec5be 这个提交带来的改动。执行 git revert对于撤销某个提交非常有用，同时又不会修改分支的历史。
cherry-pick
当活动分支需要某个分支的某个提交包含的改动时，我们可以用cherry-pick命令。通过cherry-pick某个提交，在当前活动分支上会创建一个新提交，包含了前者带来的改动。
假设 dev 分支上的提交76d12改动了index.js文件，我们在master分支上也需要。我们不需要整个分支上的改动，只要这个提交。
Alt Text
666，master分支现在也包含了76d12提交的改动了。
fetch
如果存在远程分支，远程分支可能有些提交是当前的本地分支没有的。有可能是其他分支合并过去了，或者你的同事推送了某些改动，等等。
我们可以用 git fetch 把这些改动获取到本地。这不会影响本地分支，fetch只是下载数据。
Alt Text
现在就可以看到从最近一次推送以来的所有变动。本地有了这些新数据，我们就可以决定如何使用了。
pull
除了用git fetch 获取远程分支信息外，还可以用git pull。git pull实际上是两个命令合而为一：git fetch和git merge。当我们从 origin 拉取改动时，先是像git fetch一样获取所有数据，然后最新改动会自动合并到本地分支。
Alt Text
这样就跟远程分支保持同步了，包含了所有的最新改动。
reflog
每个人都会犯错误，这完全没有关系！有时候你可能觉得自己把仓库搞得一团糟，只想把它删了完事。
git reflog是个非常有用的命令，可以显示所有操作的日志。包括 merge，reset，revert 等，基本上包括了对分支的任何更改。
Alt Text
如果出错了，你可以根据reflog提供的信息通过重置HEAD 来撤销改动。
比如，我们实际上并不想合并分支。当我们执行 git reflog命令时，我们看到在合并前仓库位于 HEAD@{1}。我们执行下git reset命令，让 HEAD 重新指回原来的HEAD@{1}位置。
Alt Text
我们可以看到，最新的操作也记录到reflog里了。
总结
Git 还有很多有用的命令，篇幅所限不能一一列举。希望通过上面这些形象的动画演示，你能够更好地理解这些分支操作。
看到这个颇有气质的 logo，不来关注下吗？
image
网友评论