git-reset - 云端在线

程序：

您的姓名

git-reset - 将当前 HEAD 重置为指定状态

概要

混帐 重置 [-q] [ ] [--] ...
混帐 重置 (--patch | -p) [ ] [--] [ ...]
混帐 重置 [--软| --混合 [-N] | --硬 | --合并 | --保持] [-q] [ ]

商品描述

在第一种和第二种形式中，从到索引。 在第三
表单，设置当前分支头（HEAD）为, 可选地修改索引和
工作树匹配。 这/ 在所有形式中默认为 HEAD。

混帐 重置 [-q] [ ] [--] ...
此表单重置所有索引条目到他们的状态. （它
不影响工作树或当前分支。）

这意味着 git reset 与 git add 相反.

运行 git reset 后要更新索引条目，您可以使用 混帐结帐(1)
将索引中的内容检查到工作树。 或者，使用 混帐-
结帐(1)并指定一个commit，你可以将一个路径的内容从一个
一次性提交到索引和工作树。

混帐 重置 (--patch | -p) [ ] [--] [ ...]
交互式选择索引之间的差异的大块头
（默认为 HEAD）。 所选的大块被反向应用到索引。

这意味着 git reset -p 与 git add -p 相反，即您可以使用它来
有选择地重置帅哥。 请参阅“交互模式”部分 混帐添加(1) 学习方法
操作 --patch 模式。

混帐 重置 [ ] [ ]
此表单将当前分支头重置为并可能更新索引
（将其重置为) 和工作树取决于. 如果
省略，默认为“--mixed”。 这必须是以下之一：

--软
根本不接触索引文件或工作树（但将头部重置为
，就像所有模式一样）。 这会使您所有更改的文件“更改为
承诺”，如 混帐 状态 会把它。

--混合
重置索引但不重置工作树（即，保留更改的文件
但未标记为提交）并报告尚未更新的内容。 这是
默认操作。

如果指定了 -N，则删除的路径被标记为意图添加（请参阅 混帐添加（1））。

- 难的
重置索引和工作树。 对工作中跟踪文件的任何更改
树自被丢弃。

- 合并
重置索引并更新工作树中不同的文件
之间和 HEAD，但保留索引之间不同的那些
和工作树（即具有尚未添加的更改）。 如果一个文件
这是不同的并且索引有未分阶段的变化，重置是
中止。

换句话说，--merge 做一些类似的事情 混帐 读树 -u -m ，但
结转未合并的索引条目。

- 保持
重置索引条目并更新工作树中不同的文件
之间和头。 如果不同的文件和头
有本地更改，重置被中止。

如果要撤消分支上最新提交以外的提交， git 恢复(1) 是你的
朋友。

配置

-q, --安静
安静，只报告错误。

示例

撤消添加

$编辑 (1)
$ git 添加 frotz.c filfre.c
$mailx (2)
$ git重置 (3)
$ git pull git://info.example.com/ nitfol (4)

1. 您正在愉快地工作，并发现这些文件中的更改在
良好的秩序。 你不想在运行“git diff”时看到它们，因为你打算
处理其他文件和更改这些文件会分散注意力。
2. 有人让你拉，这些变化听起来值得合并。
3. 但是，您已经弄脏了索引（即您的索引与 HEAD 不匹配
犯罪）。 但是您知道您要进行的拉动不会影响 frotz.c 或
filfre.c，因此您可以恢复这两个文件的索引更改。 你的工作变化
树留在那里。
4. 然后你可以拉和合并，留下 frotz.c 和 filfre.c 的变化仍然在
工作树。

撤消提交并重做

$ git提交...
$ git reset --soft HEAD^ (1)
$编辑 (2)
$ git commit -a -c ORIG_HEAD (3)

1. 当你记得你刚刚提交的内容不完整时，通常会这样做，
或者你拼错了提交信息，或者两者都有。 像以前一样离开工作树
“重启”。
2. 对工作树文件进行更正。
3. “重置”将旧头复制到 .git/ORIG_HEAD; 通过从其开始重做提交
日志消息。 如果你不需要进一步编辑消息，你可以给 -C 选项
代替。

另请参阅 --amend 选项 git提交（1）。

撤消提交，使其成为主题分支

$ git 分支主题/wip (1)
$ git reset --hard HEAD~3 (2)
$ git checkout 主题/wip (3)

1. 你做了一些提交，但意识到他们在“主人”中为时过早
分支。 您想在主题分支中继续完善它们，因此创建“topic/wip”
当前 HEAD 的分支。
2. 回滚主分支以摆脱这三个提交。
3. 切换到“topic/wip”分支并继续工作。

撤消永久提交

$ git提交...
$ git reset --hard HEAD~3 (1)

1. 最后三个提交（HEAD、HEAD^ 和 HEAD~2）很糟糕，你不想
再也见不到他们了。 做 而不去 如果您已经做出这些承诺，请执行此操作
其他人。 （请参阅“从上游 REBASE 中恢复”部分 git 变基（1）
这样做的影响。）

撤消合并或拉取

$ git拉 (1)
自动合并硝基苯
CONFLICT（内容）：在 nitfol 中合并冲突
自动合并失败； 修复冲突，然后提交结果。
$ git 重置 --hard (2)
$ git pull 。 主题/分支 (3)
从 41223... 更新到 13134...
快进
$ git reset --hard ORIG_HEAD (4)

1. 尝试从上游更新导致很多冲突； 你还没准备好
现在花很多时间合并，所以你决定以后再做。
2. “pull”还没有进行合并提交，所以“git reset --hard”是“git”的同义词
reset --hard HEAD”清除索引文件和工作树中的混乱。
3. 将主题分支合并到当前分支中，这会导致快进。
4. 但是您认为主题分支尚未准备好供公众使用。
“拉”或“合并”总是在 ORIG_HEAD 中保留当前分支的原始尖端，
所以努力重置它会使您的索引文件和工作树恢复到那个状态
状态，并将分支的尖端重置为该提交。

撤消合并或拉入肮脏的工作树

$ git拉 (1)
自动合并硝基苯
通过递归进行合并。
硝基苯 | 20 +++++----
...
$ git reset --merge ORIG_HEAD (2)

1. 即使您的工作树中可能有本地修改，您也可以放心地说
“git pull” 当您知道另一个分支中的更改与
他们。
2. 检查合并的结果后，您可能会发现其他
分支不满意。 运行“git reset --hard ORIG_HEAD”会让你回到
您所在的位置，但它会丢弃您不想要的本地更改。 “混蛋
reset --merge”保留您的本地更改。

中断的工作流程
假设您在处理某个问题时被紧急修复请求打断了
大变化。 您工作树中的文件还没有提交任何形状，
但是您需要到另一个分支进行快速错误修复。

$ git checkout feature ;# 您在“功能”分支中工作并且
$ work work work ;#被打断了
$ git commit -a -m "快照 WIP" (1)
$ git结账大师
$修复修复修复
$ git commit ;# 使用真实日志提交
$ git 结帐功能
$ git reset --soft HEAD^ ;# 回到 WIP 状态 (2)
$ git重置 (3)

1. 这个提交会被吹走，所以丢弃的日志消息是可以的。
2. 这消除了 WIP 从提交历史提交，并将您的工作树设置为
制作快照之前的状态。
3. 此时索引文件仍然包含您提交的所有 WIP 更改
快照 WIP. 这会更新索引以将 WIP 文件显示为未提交。

参见 git 存储（1）。

重置索引中的单个文件
假设您已将文件添加到索引中，但后来决定不想添加
它给你的承诺。 您可以在保留更改的同时从索引中删除文件
用 git 重置。

$ git 重置 -- frotz.c (1)
$ git commit -m "提交索引中的文件" (2)
$ git添加frotz.c (3)

1. 这会将文件从索引中删除，同时将其保留在工作目录中。
2. 这将提交索引中的所有其他更改。
3. 再次将文件添加到索引中。

保留工作树中的更改，同时丢弃一些先前的提交
假设你正在做某事并提交它，然后你继续工作
多一点，但是现在您认为您的工作树中的内容应该在
另一个与您之前提交的内容无关的分支。 你可以
启动一个新分支并重置它，同时保留工作树中的更改。

$ git 标签开始
$ git checkout -b 分支1
$编辑
$ git提交... (1)
$编辑
$ git checkout -b 分支2 (2)
$ git reset --keep 开始 (3)

1. 这将提交您在 branch1 中的第一次编辑。
2. 在理想的世界中，您可能已经意识到较早的提交不属于
创建并切换到 branch2 时转到新主题（即“git checkout -b
branch2 start”），但没有人是完美的。
3. 但是您可以使用“reset --keep”在切换到
“分支2”。

讨论

下表显示了运行时发生的情况：

git reset --option 目标

使用不同的重置选项将 HEAD 重置为另一个提交（目标），具体取决于
文件的状态。

在这些表中，A、B、C 和 D 是文件的一些不同状态。 例如，第一个
第一个表的行表示如果文件在工作树中处于状态 A，则处于状态 B
在索引中，在 HEAD 中的状态 C 和目标中的状态 D 中，然后“git reset --soft
目标”将把文件留在工作树中的状态 A 和索引中的状态 B。它
重置（即移动）HEAD（即当前分支的尖端，如果你在一个分支上）到
“目标”（文件处于状态 D）。

工作指标 HEAD 目标工作指标 HEAD
-------------------------------------------------- -
ABCD --软ABD
--混合添加
--硬DDD
--merge（不允许）
--keep (不允许)

工作指标 HEAD 目标工作指标 HEAD
-------------------------------------------------- -
ABCC --软ABC
--混合ACC
--硬CCC
--merge（不允许）
--保持ACC

工作指标 HEAD 目标工作指标 HEAD
-------------------------------------------------- -
英国广播公司 -- 软 BBD
--混合BDD
--硬DDD
--合并DDD
--keep (不允许)

工作指标 HEAD 目标工作指标 HEAD
-------------------------------------------------- -
英国广播公司 --soft BBC
--混合密件抄送
--硬CCC
--合并CCC
--保留密件抄送

工作指标 HEAD 目标工作指标 HEAD
-------------------------------------------------- -
BCCD --软BCD
--混合BDD
--硬DDD
--merge（不允许）
--keep (不允许)

工作指标 HEAD 目标工作指标 HEAD
-------------------------------------------------- -
密件抄送--软密件抄送
--混合密件抄送
--硬CCC
--合并密件抄送
--保留密件抄送

“reset --merge”旨在在冲突合并中重置时使用。 任何合并
操作保证合并中涉及的工作树文件不
在索引开始之前对其进行本地更改，并将结果写入
工作树。 因此，如果我们看到索引和目标之间存在一些差异，并且
在索引和工作树之间，那么这意味着我们不是从一个
说明在因冲突而失败后留下了合并操作。 这就是为什么我们不允许
--merge 选项在这种情况下。

“reset --keep”用于删除当前的一些最后提交
分支，同时保持工作树中的更改。 如果两者之间可能发生冲突
我们要删除的提交中的更改以及我们要删除的工作树中的更改
保持，不允许重置。 这就是为什么如果有两个更改则不允许
在工作树和 HEAD 之间，以及在 HEAD 和目标之间。 为安全起见，这也是
有未合并的条目时不允许。

下表显示存在未合并条目时会发生什么：

工作指标 HEAD 目标工作指标 HEAD
-------------------------------------------------- -
XUAB --soft（不允许）
--混合XBB
--硬BBB
--合并BBB
--keep (不允许)

工作指标 HEAD 目标工作指标 HEAD
-------------------------------------------------- -
XUAA --soft (不允许)
--混合XAA
--硬AAA
--合并AAA
--keep (不允许)

X 表示任何状态，U 表示未合并的索引。

GIT

部分 混帐(1) 套房

使用 onworks.net 服务在线使用 git-reset