git“撤销”“恢复”使用 笔记
2017-06-23 14:31
369 查看
撤销一个“已公开”的改变
撤销一个“已公开”的改变
场景: 你已经执行了
方法:
原理:
这是 Git 最安全、最基本的撤销场景,因为它并不会改变历史 — 所以你现在可以 git push 新的“反转” commit 来抵消你错误提交的 commit。
修正最后一个 commit 消息
场景: 你在最后一条 commit 消息里有个笔误,已经执行了 git commit -m "Fxies bug #42",但在 git push 之前你意识到消息应该是 “Fixes bug #42″。
方法:
原理:
撤销“本地的”修改
场景: 一只猫从键盘上走过,无意中保存了修改,然后破坏了编辑器。不过,你还没有 commit 这些修改。你想要恢复被修改文件里的所有内容 — 就像上次 commit 的时候一模一样。
方法:
原理:
记住:你用这种方法“撤销”的任何修改真的会完全消失。因为它们从来没有被提交过,所以之后 Git 也无法帮助我们恢复它们。你要确保自己了解你在这个操作里扔掉的东西是什么!(也许可以先利用 git diff 确认一下)
重置“本地的”修改
场景: 你在本地提交了一些东西(还没有 push),但是所有这些东西都很糟糕,你希望撤销前面的三次提交 — 就像它们从来没有发生过一样。
方法:
原理:
在撤销“本地修改”之后再恢复
场景: 你提交了几个 commit,然后用 git reset --hard 撤销了这些修改(见上一段),接着你又意识到:你希望还原这些修改!
方法:
原理:
你可能已经熟悉了 git log 命令,它会显示 commit 的列表。 git reflog 也是类似的,不过它显示的是一个 HEAD 发生改变的时间列表.
一些注意事项:
它涉及的只是 HEAD 的改变。在你切换分支、用 git commit 进行提交、以及用 git reset 撤销 commit 时,HEAD 会改变,但当你用
你的 reflog 就是你的,只是你的。你不能用
reflog
撤销一个“已公开”的改变
场景: 你已经执行了
git push, 把你的修改发送到了 GitHub,现在你意识到这些 commit 的其中一个是有问题的,你需要撤销那一个 commit.
方法:
git revert <SHA>
原理:
git revert会产生一个新的 commit,它和指定 SHA 对应的 commit 是相反的(或者说是反转的)。如果原先的 commit 是“物质”,新的 commit 就是“反物质” — 任何从原先的 commit 里删除的内容会在新的 commit 里被加回去,任何在原先的 commit 里加入的内容会在新的 commit 里被删除。
这是 Git 最安全、最基本的撤销场景,因为它并不会改变历史 — 所以你现在可以 git push 新的“反转” commit 来抵消你错误提交的 commit。
修正最后一个 commit 消息
场景: 你在最后一条 commit 消息里有个笔误,已经执行了 git commit -m "Fxies bug #42",但在 git push 之前你意识到消息应该是 “Fixes bug #42″。
方法:
git commit --amend或
git commit --amend -m "Fixes bug #42"
原理:
git commit --amend会用一个新的 commit 更新并替换最近的 commit ,这个新的 commit 会把任何修改内容和上一个 commit 的内容结合起来。如果当前没有提出任何修改,这个操作就只会把上次的 commit 消息重写一遍。
撤销“本地的”修改
场景: 一只猫从键盘上走过,无意中保存了修改,然后破坏了编辑器。不过,你还没有 commit 这些修改。你想要恢复被修改文件里的所有内容 — 就像上次 commit 的时候一模一样。
方法:
git checkout -- <bad filename>
原理:
git checkout会把工作目录里的文件修改到 Git 之前记录的某个状态。你可以提供一个你想返回的分支名或特定 SHA ,或者在缺省情况下,Git 会认为你希望 checkout 的是 HEAD,当前 checkout 分支的最后一次 commit。
记住:你用这种方法“撤销”的任何修改真的会完全消失。因为它们从来没有被提交过,所以之后 Git 也无法帮助我们恢复它们。你要确保自己了解你在这个操作里扔掉的东西是什么!(也许可以先利用 git diff 确认一下)
重置“本地的”修改
场景: 你在本地提交了一些东西(还没有 push),但是所有这些东西都很糟糕,你希望撤销前面的三次提交 — 就像它们从来没有发生过一样。
方法:
git reset <last good SHA>或
git reset --hard <last good SHA>
原理:
git reset会把你的代码库历史返回到指定的 SHA 状态。 这样就像是这些提交从来没有发生过。缺省情况下, git reset 会保留工作目录。这样,提交是没有了,但是修改内容还在磁盘上。这是一种安全的选择,但通常我们会希望一步就“撤销”提交以及修改内容 — 这就是 --hard 选项的功能。
在撤销“本地修改”之后再恢复
场景: 你提交了几个 commit,然后用 git reset --hard 撤销了这些修改(见上一段),接着你又意识到:你希望还原这些修改!
方法:
git reflog 和 git reset或
git checkout
原理:
git reflog对于恢复项目历史是一个超棒的资源。你可以恢复几乎 任何东西 — 任何你 commit 过的东西 — 只要通过 reflog。
你可能已经熟悉了 git log 命令,它会显示 commit 的列表。 git reflog 也是类似的,不过它显示的是一个 HEAD 发生改变的时间列表.
一些注意事项:
它涉及的只是 HEAD 的改变。在你切换分支、用 git commit 进行提交、以及用 git reset 撤销 commit 时,HEAD 会改变,但当你用
git checkout -- <bad filename>撤销时(正如我们在前面讲到的情况),HEAD 并不会改变 — 如前所述,这些修改从来没有被提交过,因此 reflog 也无法帮助我们恢复它们。
git reflog不会永远保持。Git 会定期清理那些 “用不到的” 对象。不要指望几个月前的提交还一直躺在那里。
你的 reflog 就是你的,只是你的。你不能用
git reflog来恢复另一个开发者没有 push 过的 commit。
reflog
相关文章推荐
- git 使用小技巧之撤销提交操作与恢复更改前操作
- git使用笔记
- git使用笔记
- 《版本控制之道--使用Git》笔记
- Git bash使用笔记
- git使用笔记
- 给您的文字编辑程序添加一剂“后悔药”-使用RichTextBox控件提供用户编辑功能,加入类似word的“撤销”和“恢复”功能
- git 安装使用笔记
- ubuntu下git安装与使用笔记
- GitTortoise + Git Source Control Provider使用笔记
- git 安装使用笔记
- Git安装使用笔记 [转]
- GIT学习笔记1--基本使用
- GIT使用笔记
- ubuntu下git安装与使用笔记
- 一次有趣的Debug——使用Lumigent Log Explorer对SQL Server事务日志进行分析,对SQL Server事务、操作进行撤销(恢复)
- Git使用笔记
- Git使用笔记(二)-可视化Merge工具Meld
- git 安装使用笔记
- ubuntu 下git安装及使用笔记