计算机学院网站建设,免费网站空间女人,兰州市做网站的,网站开发技术难点优质文章#xff0c;第一时间送达#xff01;来源#xff1a;机器之心git merge、git rebase、git reset、git revert、git fetch、git pull、git reflog……你知道这些 git 命令执行的究竟是什么任务吗#xff1f;如果你还有些分不清楚#xff0c;那千万不能错过这篇文章…优质文章第一时间送达来源机器之心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 通过动图形式直观地介绍了这些常用 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 会将当前分支的提交复制到指定的分支之上。完美现在我们在 dev 分支上获取了 master 分支上的所有修改。变基与合并有一个重大的区别Git 不会尝试确定要保留或不保留哪些文件。我们执行 rebase 的分支总是含有我们想要保留的最新近的修改这样我们不会遇到任何合并冲突而且可以保留一个漂亮的、线性的 Git 历史记录。上面这个例子展示了在 master 分支上的变基。但是在更大型的项目中你通常不需要这样的操作。git rebase 在为复制的提交创建新的 hash 时会修改项目的历史记录。如果你在开发一个 feature 分支并且 master 分支已经更新过那么变基就很好用。你可以在你的分支上获取所有更新这能防止未来出现合并冲突。交互式变基(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 上的分支当远程分支上包含当前分支没有的提交时可以使用取回。比如当合并了另一个分支或你的同事推送了一个快速修复时。通过在这个远程分支上执行 git fetch我们就可在本地获取这些修改。这不会以任何方式影响你的本地分支fetch 只是单纯地下载新的数据而已。现在我们可以看到自上次推送以来的所有修改了。这些新数据也已经在本地了我们可以决定用这些新数据做什么了。拉取(Pulling)尽管 git fetch 可用于获取某个分支的远程信息但我们也可以执行 git pull。git pull 实际上是两个命令合成了一个git fetch 和 git merge。当我们从来源拉取修改时我们首先是像 git fetch 那样取回所有数据然后最新的修改会自动合并到本地分支中。很好我们现在与远程分支完美同步了并且也有了所有最新的修改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」立即获取主页君与小伙伴一起翻译的《Think Python 2e》电子版回复关键词「入门资料」立即获取主页君整理的 10 本 Python 入门书的电子版回复关键词「m」立即获取Python精选优质文章合集回复关键词「」将数字替换成 0 及以上数字有惊喜好礼哦~题图pexelsCC0 授权。好文章我在看
