Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.44.1 → 2.47.0 no changes
- 2.44.0 02/23/24
- 2.43.1 → 2.43.5 no changes
- 2.43.0 11/20/23
- 2.39.1 → 2.42.3 no changes
- 2.39.0 12/12/22
- 2.38.1 → 2.38.5 no changes
- 2.38.0 10/02/22
- 2.37.1 → 2.37.7 no changes
- 2.37.0 06/27/22
- 2.30.1 → 2.36.6 no changes
- 2.30.0 12/27/20
- 2.27.1 → 2.29.3 no changes
- 2.27.0 06/01/20
- 2.23.1 → 2.26.3 no changes
- 2.23.0 08/16/19
- 2.22.1 → 2.22.5 no changes
- 2.22.0 06/07/19
- 2.10.5 → 2.21.4 no changes
- 2.9.5 07/30/17
- 2.8.6 no changes
- 2.7.6 07/30/17
- 2.6.7 05/05/17
- 2.1.4 → 2.5.6 no changes
- 2.0.5 12/17/14
概述
git revert [--[no-]edit] [-n] [-m <父提交数量>] [-s] [-S[<键 ID>]] <提交>… git revert (--continue | --skip | --abort | --quit)
描述
给定一个或多个现有提交,还原相关补丁引入的更改,并记录一些新提交来记录这些更改。 这要求你的工作区是干净的(没有对 HEAD 提交的修改)。
注意:git revert 用于记录一些新的提交,以扭转先前提交(通常只是错误的提交)的影响。 如果您想丢弃工作目录中所有未提交的改动,请参阅 git-reset[1],尤其是 --hard
选项。 如果你想提取其他提交中的特定文件,请参阅 git-restore[1],尤其是 `--source`选项。使用这些选项时要小心,因为它们都会丢弃工作目录中未提交的改动。
关于这三个命令的区别,见git[1]中的 "重置、恢复和还原"。
选项
- <提交>…
-
要还原的提交。 更完整的提交名拼写方式,请参见 gitrevisions[7]。 也可以给出提交集,但默认情况下不进行遍历,参见 git-rev-list[1] 及其 `--no-walk`选项。
- -e
- --edit
-
有了这个选项,git revert 会让你在提交之前编辑提交信息。如果从终端运行该命令,默认情况下也是如此。
- -m 父编号
- --mainline parent-number
-
通常情况下,由于不知道合并的哪一方应被视为主线,因此无法还原合并。 该选项指定了主线的父线编号(从 1 开始),允许还原指令相对于指定的父线反向更改。
还原合并提交就意味着你永远不需要合并带来的目录树变化。 因此,以后的合并只会引入目录树变化,而这些变化不是由先前已还原合并的祖先提交引入的。 这可能是你想要的,也可能不是。
更多详情,请参阅 revert-a-faulty-merge 如何操作。
- --no-edit
-
使用该选项后,git revert 将不会启动提交信息编辑器。
- --cleanup=<模式>
-
这个选项决定了提交信息在传递给提交机制之前将如何进行清理。更多细节见 git-commit[1]。特别是,如果 <模式> 的值为
scissors
,那么在发生冲突时,scissors
将被附加到MERGE_MSG
上。 - -n
- --no-commit
-
通常,该命令会自动创建一些提交,并在提交日志信息中说明哪些提交被还原。 该标记会对工作区和索引进行必要的修改,以还原指定的提交,但不会进行提交。 此外,使用该选项时,索引不必与 HEAD 提交相匹配。 还原是针对索引的起始状态进行的。
这在连续恢复多个提交对索引的影响时非常有用。
- -S[<keyid>]
- --gpg-sign[=<键 ID>]
- --no-gpg-sign
-
GPG 签名提交。
keyid
参数是可选的,默认为提交者身份;如果指定了,则必须与选项相连,不加空格。--no-gpg-sign
用于还原commit.gpgSign
配置变量和先前的--gpg-sign
。 - -s
- --signoff
-
在提交信息的末尾添加一个
Signed-off-by
的尾注。 更多信息见 git-commit[1] 中的 signoff 选项。 - --strategy=<策略>
-
使用给定的合并策略。 应该只使用一次。 详见 git-merge[1] 中的合并策略部分。
- -X<选项>
- --strategy-option=<选项>
-
将合并策略特有的选项传递给合并策略。 详见 git-merge[1]。
- --rerere-autoupdate
- --no-rerere-autoupdate
-
在 rerere 机制重用当前冲突的记录解析来更新工作树中的文件后,允许它也用解析的结果来更新索引。
--no-rerere-autoupdate`是一个很好的方法,在用单独的 `git add
提交结果到索引之前,可以反复检查rerere
所做的事情,并抓住潜在的错误合并。
- --reference
-
而不是以 “他还原了 <完整的提交对象名称>。” 作为日志信息的开头,而是使用 "--pretty=reference" 格式来引用提交(参见 git-log[1])。
revert.reference
配置变量可用于默认启用此选项。
讨论
虽然 git 会自动创建基本的提交信息,但强烈建议解释为什么要还原原始提交。 此外,反复还原会导致主题行越来越笨重,例如 "Reapply "Reapply "<original subject>""。 请考虑重新措辞,使其更简短、更独特。
配置
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
GIT
属于 git[1] 文档