高质量该文，第三时间送抵！
git merge、git rebase、git reset、git revert、git fetch、git pull、git reflog……你知道那些 git 指示继续执行的到底是什么各项任务吗？假如你还很多分不清，那一千万不能错失这首诗。在责任编辑中，津津乐道 JavaScript、TypeScript、GraphQL、Serverless、AWS、Docker 和 Golang 的 21 岁年青应用软件高级顾问 Lydia Hallie 通过Zopfli方式简单地如是说了那些常见 git 指示的工作操作过程，包你眼前一亮。
虽然 Git 是这款十分强悍的辅助工具，但假如我说 Git 用起来实在是恶梦，绝大多数人也会尊重我的讲法。我发现在采用 Git 时，在洞察力里建模地想像它会十分管用：当我继续执行两个某一指示时，那些组成部分会怎样可视化，又会什么样影响历史纪录？为何当我在 master 上继续执行硬重新启动，force push 到原组成部分以及 rimraf 他们的 .git 实用性文件时，我的同僚哭了？
我真的建立一些最常见且最管用的 Git 指示的建模实例会是两个轻松的示例！上面我将如是说的许多指示都有较旧模块——你能采用那些模块来发生改变相关联指示的犯罪行为。而我的实例只会囊括指示的预设犯罪行为，而不能加进（或加进太少）较旧实用性！
责任编辑译者Lydia Hallie。
分拆
保有数个组成部分是很方便快捷的，这样能将不同的新修正相互相连接，而且还能保证你不能不幸向制造标识符发送转载或剥落的标识符修正。但除非那些修正获得了核准许可证，他们就需要将其布署到他们的制造组成部分中！
可将两个组成部分的修正融入到另两个组成部分的一种方式是继续执行 git merge。Git 可继续执行两种类型的分拆：fast-forward 和 no-fast-forward。现在你可能分不清，但他们马上就来看看它们的差异所在。
Fast-forward (—ff)
在当前组成部分相比于他们要分拆的组成部分没有额外的提交（commit）时，能继续执行 fast-forward 分拆。Git 很懒，首先会尝试继续执行最简单的选项：fast-forward！这类分拆不能建立新的提交，而是会将他们正在分拆的组成部分上的提交直接分拆到当前组成部分。
轻松！现在，他们在 dev 组成部分上所做的所有发生改变都分拆到了 master 组成部分上。那么 no-fast-forward 又是什么意思呢？
No-fast-foward (—no-ff)
假如你的当前组成部分相比于你想要分拆的组成部分没有任何提交，那当然很好，但很遗憾现实情况很少如此！假如他们在当前组成部分上提交他们想要分拆的组成部分不具备的发生改变，那么 git 将会继续执行 no-fast-forward 分拆。
采用 no-fast-forward 分拆时，Git 会在当前活动组成部分上建立新的 merging commit。这个提交的父提交（parent commit）即指向这个活动组成部分，也指向他们想要分拆的组成部分！
没什么大不了的，轻松的分拆！现在，他们在 dev 组成部分上所做的所有发生改变都分拆到了 master 组成部分上。
分拆冲突
虽然 Git 能够很好地决定怎样分拆组成部分以及怎样向文件加进修正，但它并不总是能完全自己做决定。当他们想要分拆的两个组成部分的同一文件中的同一行标识符上有不同的修正，或者两个组成部分删除了两个文件而另两个组成部分修正了这个文件时，Git 就不知道怎样取舍了。
在这样的情况下，Git 会询问你想要保留哪种选择？假设在这两个组成部分中，他们都编辑了 README.md 的第三行。
假如他们想把 dev 分拆到 master，就会出现两个分拆冲突：你想要标题是 Hello! 还是 Hey!？
当尝试分拆那些组成部分时，Git 会向你展示冲突出现的位置。他们能手动移除他们不想保留的修正，保存那些修正，再次加进这个已修正的文件，然后提交那些修正。
完成！虽然分拆冲突往往很让人厌烦，但这是合理的：Git 不应该瞎猜他们想要保留哪些修正。
变基（Rebasing）
他们刚看到可通过继续执行 git merge 将两个组成部分的修正应用到另两个组成部分。另一种可将两个组成部分的修正融入到另两个组成部分的方式是继续执行 git rebase。
git rebase 会将当前组成部分的提交复制到指定的组成部分之上。
变基与分拆有两个重大的区别：Git 不能尝试确定要保留或不保留哪些文件。他们继续执行 rebase 的组成部分总是含有他们想要保留的最新近的修正！这样他们不能遇到任何分拆冲突，而且能保留两个漂亮的、线性的 Git 历史纪录。
上面这个例子展示了在 master 组成部分上的变基。但是，在更大型的项目中，你通常不需要这样的操作。git rebase 在为复制的提交建立新的 hash 时会修正项目的历史纪录。
假如你在开发两个 feat
可视化式变基（Interactive Rebase）
在为提交继续执行变基之前，他们能修正它们！他们能采用可视化式变基来完成这一各项任务。可视化式变基在你当前开发的组成部分上以及想要修正某些提交时会很管用。
在他们正在 rebase 的提交上，他们能继续执行以下 6 个动作：
reword：修正提交信息；
edit：修正此提交；
squash：将提交融合到前两个提交中；
fixup：将提交融合到前两个提交中，不保留该提交的日志消息；
exec：在每个提交上运行他们想要 rebase 的指示；
drop：移除该提交。
很棒！这样他们就能完全控制他们的提交了。假如你想要移除两个提交，只需 drop 即可。
假如你想把数个提交融合到一起以便获得清晰的提交历史，那也没有问题！
可视化式变基能为你在 rebase 时提供大量控制，甚至能控制当前的活动组成部分。
重置（Resetting）
当他们不想要之前提交的修正时，就会用到这个指示。也许这是两个 WIP 提交或者可能是引入了 bug 的提交，这时候就要继续执行 git reset。
git reset 能让他们不再采用当前台面上的文件，让他们能控制 HEAD 应该指向的位置。
软重置
软重置会将 HEAD 移至指定的提交（或与 HEAD 相比的提交的索引），而不能移除该提交之后加入的修正！
假设他们不想保留加进了两个 style.css 文件的提交 9e78i，而且他们也不想保留加进了两个 index.js 文件的提交 035cc。但是，他们确实又想要保留新加进的 style.css 和 index.js 文件！这是软重置的两个轻松示例。
输入 git status 后，你会看到他们仍然能访问在之前的提交上做过的所有修正。这很好，这意味着他们能修复那些文件的内容，之后再重新提交它们！
硬重置
有时候他们并不想保留某一提交引入的修正。不同于软重置，他们应该再也无需访问它们。Git 应该直接将整体状态直接重置到某一提交之前的状态：这甚至包括你在工作目录中和暂存文件上的修正。
Git 丢弃了 9e78i 和 035cc 引入的修正，并将状态重置到了 ec5be 的状态。
还原（Reverting）
另一种撤销修正的方法是继续执行 git revert。通过对某一的提交继续执行还原操作，他们会建立两个包含已还原修正的新提交。
假设 ec5be 加进了两个 index.js 文件。但之后他们发现其实他们再也不需要由这个提交引入的修正了。那就还原 ec5be 提交吧！
轻松！提交 9e78i 还原了由提交 ec5be 引入的修正。在撤销某一的提交时，git revert 十分管用，同时也不能修正组成部分的历史。
拣选（Cherry-picking）
当两个某一组成部分包含他们的活动组成部分需要的某个提交时，他们对那个提交继续执行 cherry-pick！对两个提交继续执行 cherry-pick 时，他们会在活动组成部分上建立两个新的提交，其中包含由拣选出来的提交所引入的修正。
假设 dev 组成部分上的提交 76d12 为 index.js 文件加进了一项修正，而他们希望将其整合到 master 组成部分中。他们并不想要整个 dev 组成部分，而只需要这个提交！
现在 master 组成部分包含 76d12 引入的修改了。
取回（Fetching）
假如你有两个远程 Git 组成部分，比如在 GitHub 上的组成部分，当远程组成部分上包含当前组成部分没有的提交时，能采用取回。比如当分拆了另两个组成部分或你的同僚发送了两个快速修复时。
现在他们能看到自上次发送以来的所有修正了。那些新数据也已经在本地了，他们能决定用那些新数据做什么了。
拉取（Pulling）
很好，他们现在与远程组成部分轻松同步了，并且也有了所有最新的修正！
Reflog
每个人都会犯错，但犯错其实没啥！有时候你可能感觉你把 git repo 完全搞坏了，让你想完全删了了事。
git reflog 是两个十分管用的指示，能展示已经继续执行过的所有动作的日志。包括分拆、重置、还原，基本上包含你对你的组成部分所做的任何修正。
假如你犯了错，你能根据 reflog 提供的信息通过重置 HEAD 来轻松地重做！
假设他们实际上并不需要分拆原有组成部分。当他们继续执行 git reflog 指示时，他们能看到这个 repo 的状态在分拆前位于 HEAD@{1}。那他们就继续执行一次 git reset，将 HEAD 重新指向在 HEAD@{1} 的位置。
他们能看到最新的动作已被发送给 reflog。
原文链接：
https://dev.to/lydiahallie/cs-visualized-useful-git-commands-37p1方「关键词」
pybook03
入门资料入门书的电子版
m
题图：pexels，CC0 授权。
好该文，我在看
