如何在 Git 中重置、恢复,返回到以前的状态
2018-08-13 09:23
513 查看
用简洁而优雅的 Git 命令撤销仓库中的改变。
使用 Git 工作时其中一个鲜为人知(和没有意识到)的方面就是,如何轻松地返回到你以前的位置 —— 也就是说,在仓库中如何很容易地去撤销那怕是重大的变更。在本文中,我们将带你了解如何去重置、恢复和完全回到以前的状态,做到这些只需要几个简单而优雅的 Git 命令。
先看一下图 1。在这里我们有一个在 Git 中表示一系列提交的示意图。在 Git 中一个分支简单来说就是一个命名的、指向一个特定的提交的可移动指针。在这里,我们的 master 分支是指向链中最新提交的一个指针。
图 1:有仓库、暂存区、和工作目录的本地环境
如果看一下我们的 master 分支是什么,可以看一下到目前为止我们产生的提交链。
或:
图 2 展示了操作的结果。在这之后,如果我们在当前分支(master)上运行一个
图 2:在
这些选项在特定情况下非常有用,比如,
另一个方法是添加一个新的提交去删除第三行,以使最终结束变成两行的版本 —— 实际效果也是取消了那个更改。使用一个
如果我们现在运行一个
图 3
当我们以这种方式使用 Git 工作时,我们的基本规则之一是:在你的本地仓库中使用这种方式去更改还没有推送的代码是可以的。如果提交已经推送到了远程仓库,并且可能其它人已经使用它来工作了,那么应该避免这些重写提交历史的更改。
总之,如果你想回滚、撤销或者重写其它人已经在使用的一个提交链的历史,当你的同事试图将他们的更改合并到他们拉取的原始链上时,他们可能需要做更多的工作。如果你必须对已经推送并被其他人正在使用的代码做更改,在你做更改之前必须要与他们沟通,让他们先合并他们的更改。然后在这个侵入操作没有需要合并的内容之后,他们再拉取最新的副本。
你可能注意到了,在我们做了
图 4:master 和 feature 分支的提交链
如果我们在分支中看它的提交记录,它们看起来应该像下面的这样。(为了易于理解,
因此,我们使用基本的 Git 命令,可以变基一个 feature 分支进入到 master 中,并将它拼入到
图 5:
接着,我们看一下提交历史,它应该变成如下的样子。
如果我们做了这个变基,然后确定这不是我们想要的结果,希望去撤销它,我们可以做下面示例所做的操作:
图 6:撤销
如果你想不起来之前一个操作指向的一个分支上提交了什么内容怎么办?幸运的是,Git 命令依然可以帮助你。用这种方式可以修改大多数操作的指针,Git 会记住你的原始提交。事实上,它是在
via: https://opensource.com/article/18/6/git-reset-revert-rebase-commands
使用 Git 工作时其中一个鲜为人知(和没有意识到)的方面就是,如何轻松地返回到你以前的位置 —— 也就是说,在仓库中如何很容易地去撤销那怕是重大的变更。在本文中,我们将带你了解如何去重置、恢复和完全回到以前的状态,做到这些只需要几个简单而优雅的 Git 命令。
重置
我们从 Git 的reset命令开始。确实,你应该能够认为它就是一个 “回滚” —— 它将你本地环境返回到之前的提交。这里的 “本地环境” 一词,我们指的是你的本地仓库、暂存区以及工作目录。
先看一下图 1。在这里我们有一个在 Git 中表示一系列提交的示意图。在 Git 中一个分支简单来说就是一个命名的、指向一个特定的提交的可移动指针。在这里,我们的 master 分支是指向链中最新提交的一个指针。
图 1:有仓库、暂存区、和工作目录的本地环境
如果看一下我们的 master 分支是什么,可以看一下到目前为止我们产生的提交链。
如果我们想回滚到前一个提交会发生什么呢?很简单 —— 我们只需要移动分支指针即可。Git 提供了为我们做这个动作的$ git log --onelineb764644 File with three lines7c709f0 File with two lines9ef9173 File with one line
reset命令。例如,如果我们重置 master 为当前提交回退两个提交的位置,我们可以使用如下之一的方法:
(使用一个绝对的提交 SHA1 值$ git reset 9ef9173
9ef9173)
或:
(在 “current” 标签之前,使用一个相对值 -2)$ git reset current~2
图 2 展示了操作的结果。在这之后,如果我们在当前分支(master)上运行一个
git log命令,我们将看到只有一个提交。
$ git log --oneline9ef9173 File with one line
图 2:在
reset之后
git reset命令也包含使用一些选项,可以让你最终满意的提交内容去更新本地环境的其它部分。这些选项包括:
hard在仓库中去重置指向的提交,用提交的内容去填充工作目录,并重置暂存区;
soft仅重置仓库中的指针;而
mixed(默认值)将重置指针和暂存区。
这些选项在特定情况下非常有用,比如,
git reset --hard <commit sha1 | reference>这个命令将覆盖本地任何未提交的更改。实际上,它重置了(清除掉)暂存区,并用你重置的提交内容去覆盖了工作区中的内容。在你使用
hard选项之前,一定要确保这是你真正地想要做的操作,因为这个命令会覆盖掉任何未提交的更改。
恢复
git revert命令的实际结果类似于
reset,但它的方法不同。
reset命令(默认)是在链中向后移动分支的指针去“撤销”更改,
revert命令是在链中添加一个新的提交去“取消”更改。再次查看图 1 可以非常轻松地看到这种影响。如果我们在链中的每个提交中向文件添加一行,一种方法是使用
reset使那个提交返回到仅有两行的那个版本,如:
git reset HEAD~1。
另一个方法是添加一个新的提交去删除第三行,以使最终结束变成两行的版本 —— 实际效果也是取消了那个更改。使用一个
git revert命令可以实现上述目的,比如:
因为它添加了一个新的提交,Git 将提示如下的提交信息:$ git revert HEAD
图 3(在下面)展示了Revert "File with three lines"This reverts commit b764644bad524b804577684bf74e7bca3117f554.# Please enter the commit message for your changes. Lines starting# with '#' will be ignored, and an empty message aborts the commit.# On branch master# Changes to be committed:# modified: file1.txt#
revert操作完成后的结果。
如果我们现在运行一个
git log命令,我们将看到前面的提交之前的一个新提交。
这里是工作目录中这个文件当前的内容:$ git log --oneline11b7712 Revert "File with three lines"b764644 File with three lines7c709f0 File with two lines9ef9173 File with one line
$ cat <filename>Line 1Line 2
图 3
revert操作之后
恢复或重置如何选择?
为什么要优先选择revert而不是
reset操作?如果你已经将你的提交链推送到远程仓库(其它人可以已经拉取了你的代码并开始工作),一个
revert操作是让他们去获得更改的非常友好的方式。这是因为 Git 工作流可以非常好地在分支的末端添加提交,但是当有人
reset分支指针之后,一组提交将再也看不见了,这可能会是一个挑战。
当我们以这种方式使用 Git 工作时,我们的基本规则之一是:在你的本地仓库中使用这种方式去更改还没有推送的代码是可以的。如果提交已经推送到了远程仓库,并且可能其它人已经使用它来工作了,那么应该避免这些重写提交历史的更改。
总之,如果你想回滚、撤销或者重写其它人已经在使用的一个提交链的历史,当你的同事试图将他们的更改合并到他们拉取的原始链上时,他们可能需要做更多的工作。如果你必须对已经推送并被其他人正在使用的代码做更改,在你做更改之前必须要与他们沟通,让他们先合并他们的更改。然后在这个侵入操作没有需要合并的内容之后,他们再拉取最新的副本。
你可能注意到了,在我们做了
reset操作之后,原始的提交链仍然在那个位置。我们移动了指针,然后
reset代码回到前一个提交,但它并没有删除任何提交。换句话说就是,只要我们知道我们所指向的原始提交,我们能够通过简单的返回到分支的原始链的头部来“恢复”指针到前面的位置:
当提交被替换之后,我们在 Git 中做的大量其它操作也会发生类似的事情。新提交被创建,有关的指针被移动到一个新的链,但是老的提交链仍然存在。git reset <sha1 of commit>
变基
现在我们来看一个分支变基。假设我们有两个分支:master 和 feature,提交链如下图 4 所示。master 的提交链是C4->C2->C1->C0和 feature 的提交链是
C5->C3->C2->C1->C0。
图 4:master 和 feature 分支的提交链
如果我们在分支中看它的提交记录,它们看起来应该像下面的这样。(为了易于理解,
C表示提交信息)
我告诉人们在 Git 中,可以将$ git log --oneline master6a92e7a C4259bf36 C2f33ae68 C15043e79 C0$ git log --oneline feature79768b8 C5000f9ae C3259bf36 C2f33ae68 C15043e79 C0
rebase认为是 “将历史合并”。从本质上来说,Git 将一个分支中的每个不同提交尝试“重放”到另一个分支中。
因此,我们使用基本的 Git 命令,可以变基一个 feature 分支进入到 master 中,并将它拼入到
C4中(比如,将它插入到 feature 的链中)。操作命令如下:
完成以后,我们的提交链将变成如下图 5 的样子。$ git checkout feature$ git rebase masterFirst, rewinding head to replay your work on top of it...Applying: C3Applying: C5
图 5:
rebase命令完成后的提交链
接着,我们看一下提交历史,它应该变成如下的样子。
注意那个$ git log --oneline master6a92e7a C4259bf36 C2f33ae68 C15043e79 C0$ git log --oneline featurec4533a5 C564f2047 C36a92e7a C4259bf36 C2f33ae68 C15043e79 C0
C3'和
C5'— 在 master 分支上已处于提交链的“顶部”,由于产生了更改而创建了新提交。但是也要注意的是,rebase 后“原始的”
C3和
C5仍然在那里 — 只是再没有一个分支指向它们而已。
如果我们做了这个变基,然后确定这不是我们想要的结果,希望去撤销它,我们可以做下面示例所做的操作:
由于这个简单的变更,现在我们的分支将重新指向到做$ git reset 79768b8
rebase操作之前一模一样的位置 —— 完全等效于撤销操作(图 6)。
图 6:撤销
rebase操作之后
如果你想不起来之前一个操作指向的一个分支上提交了什么内容怎么办?幸运的是,Git 命令依然可以帮助你。用这种方式可以修改大多数操作的指针,Git 会记住你的原始提交。事实上,它是在
.git仓库目录下,将它保存为一个特定的名为
ORIG_HEAD的文件中。在它被修改之前,那个路径是一个包含了大多数最新引用的文件。如果我们
cat这个文件,我们可以看到它的内容。
我们可以使用$ cat .git/ORIG_HEAD79768b891f47ce06f13456a7e222536ee47ad2fe
reset命令,正如前面所述,它返回指向到原始的链。然后它的历史将是如下的这样:
在 reflog 中是获取这些信息的另外一个地方。reflog 是你本地仓库中相关切换或更改的详细描述清单。你可以使用$ git log --oneline feature79768b8 C5000f9ae C3259bf36 C2f33ae68 C15043e79 C0
git reflog命令去查看它的内容:
你可以使用日志中列出的、你看到的相关命名格式,去重置任何一个东西:$ git reflog79768b8 HEAD@{0}: reset: moving to 79768bc4533a5 HEAD@{1}: rebase finished: returning to refs/heads/featurec4533a5 HEAD@{2}: rebase: C564f2047 HEAD@{3}: rebase: C36a92e7a HEAD@{4}: rebase: checkout master79768b8 HEAD@{5}: checkout: moving from feature to feature79768b8 HEAD@{6}: commit: C5000f9ae HEAD@{7}: checkout: moving from master to feature6a92e7a HEAD@{8}: commit: C4259bf36 HEAD@{9}: checkout: moving from feature to master000f9ae HEAD@{10}: commit: C3259bf36 HEAD@{11}: checkout: moving from master to feature259bf36 HEAD@{12}: commit: C2f33ae68 HEAD@{13}: commit: C15043e79 HEAD@{14}: commit (initial): C0
一旦你理解了当“修改”链的操作发生后,Git 是如何跟踪原始提交链的基本原理,那么在 Git 中做一些更改将不再是那么可怕的事。这就是强大的 Git 的核心能力之一:能够很快速、很容易地尝试任何事情,并且如果不成功就撤销它们。$ git reset HEAD@{1}
via: https://opensource.com/article/18/6/git-reset-revert-rebase-commands
相关文章推荐
- 如何在 Git 中重置、恢复,返回到以前的状态
- 【git 使用】git 如何撤销 commit ,返回到未 commit 状态
- 【git系列之D】如何恢复windows系统下git的状态图标显示
- git问题记录--如何从从detached HEAD状态解救出来(git 命令大全)
- Git如何恢复已经删除的branch
- 如何将一条已经发生旋转的直线经过旋转后恢复到原来的水平状态?
- git相关-- git命令 及 git add后 未commit git reset --hard如何恢复
- git后修改了本地文件,如何重新还原未修改状态
- git 如何恢复只是提交到本地的文件(或者commit)
- 使用PHP处理数据库数据如何将数据返回客户端并显示当前状态
- 404页面返回状态码应该如何设置呢
- Git 提交错误后如何恢复
- Win7系统使用内置系统重置和系统刷新功能将系统恢复到初始状态
- Windows7/Win8系统如何备份与恢复到之前的状态
- Android 如何保证App切换到后台,或页面跳转后,重新打开APP、或返回之前页面时,维持其状态不变
- React-Redux 恢复列表页跳转明细页之后返回列表状态
- git 恢复到上次提交的状态
- git add后 未commit git reset --hard如何恢复
- 如何在mac环境下 将appStore里的找到的资源.png文件还原成xcode优化以前的状态
- GIT仓库如何恢复到前一次提交