first-contributions 项目实战：使用 git reset 重置提交的完整指南

first-contributions 项目实战使用 git reset 重置提交的完整指南【免费下载链接】first-contributions✨ Help beginners to contribute to open source projects项目地址: https://gitcode.com/gh_mirrors/fi/first-contributions导读在参与开源项目例如本仓库 first-contributions 的协作流程时你可能会提交错误的更改或希望让本地仓库回到某个历史节点。git reset正是用于将仓库回退到之前某个提交、并丢弃该提交之后所有更改的命令。阅读本文后你将掌握git log --oneline查看提交摘要、git reset commithash精确回退到指定提交、理解 reset 与 revert 的本质区别以及三种重置模式的适用场景避免在协作开发中误操作破坏共享历史。git reset 是什么reset是 Git 中用于将仓库回退到之前某个提交的命令回退后该提交之后产生的所有更改都会被丢弃。它是开发者日常工作中最常用的“后悔药”之一特别适合处理以下场景提交了错误的代码希望回到错误提交之前的状态本地实验性开发失控需要整体回退误将文件加入暂存区staging area需要取消暂存。在本仓库的文档体系中它属于“附加资料”additional material进阶 Git 技巧的一部分与修改提交amending、撤销提交undoing、回滚提交reverting等操作共同构成完整的提交历史管理工具箱详见 附加资料索引。reset 与 revert 的核心区别这是使用git reset前必须先厘清的概念也是原文档强调的重点git reset取消暂存文件并将我们的更改带回工作目录。它移动的是本地分支指针属于本地操作不涉及远程仓库。git revert从远程仓库中删除提交。它通过创建一个新的“反向提交”来抵消目标提交的更改从而安全地改写远程历史。简单记忆如果你尚未推送push到共享远程仓库使用git reset是安全且干净的如果提交已经被推送并被其他人拉取则应改用git revert避免给协作同伴制造冲突。更完整的 revert 操作流程包括获取 SHA、编辑提交信息、推送到远程可参考 撤销一个提交reverting-a-commit其中还包含git log --oneline输出的真实示例。第一步用 git log --oneline 查看提交摘要执行git reset之前必须先确定要回退到的目标提交。使用以下命令查看仓库中所有提交的简洁摘要git log --oneline该命令会以两个参数的形式给出每个提交的信息提交哈希commit hash的前七个字符——这是我们在 reset 命令中需要引用的内容提交信息commit message——帮助你辨认该提交做了什么。为什么是前 7 个字符Git 的完整提交哈希是基于 SHA-1 算法生成的 40 位十六进制字符串而前 7 个字符在绝大多数仓库中已足以唯一标识一个提交Git 官方也以此作为“简短哈希”的默认长度既方便阅读又便于在命令中引用。仅运行git log会输出完整的长格式哈希而--oneline标志告诉 Git 以单行简洁方式显示更易于浏览。典型的输出如下389004d added spacing in title c1b9fc1 Merge branch master into tutorials 77eaafd added tutorial for reverting a commit每一行最前面的389004d、c1b9fc1、77eaafd就是可供git reset引用的前 7 位简短提交哈希。第二步git reset 到指定提交找到目标提交哈希后执行以下命令将仓库重置到该提交git reset commithash其中commithash就是我们在git log --oneline中找到的提交哈希的前 7 个字符。执行后当前分支会回退到该提交的位置目标提交之后的所有提交及其更改将从历史中移除。结合仓库中 重置一个提交英文原文 的说明可以确认这是本仓库文档体系中推荐的标准用法先用git log --oneline找到目标哈希再用git reset hash完成回退。深入三种重置模式与典型场景原文档演示的是默认无参数的git reset用法。从仓库其他进阶文档可以进一步看到git reset的实际行为取决于传入的模式参数理解它们能让你更精准地控制重置结果默认模式mixed等价于 git reset 不带参数取消暂存文件并将更改带回工作目录——这正是原文档对 reset 的定义。执行后暂存区被重置为最近一次提交但工作目录中的更改不受影响因此你仍然可以重新提交这些更改。典型场景是“本想一次性提交多个文件后来决定分开提交”# 修改了 index.php 和 tutorial.php # 将文件添加到暂存区 $ git add . # 想起来这两个文件应该分开提交 # 取消暂存 tutorial.php $ git reset tutorial.php # 先提交 index.php $ git commit -m Changed index.php # 现在提交 tutorial.php $ git add tutorial.php $ git commit -m 修改了 tutorial.php可以看到git reset 文件名只会将指定文件从暂存区移除文件中的更改仍然保留在工作目录。完整的分步演示见 撤销本地提交undoing-a-commit。--soft 模式仅移动指针只移动分支指针到目标提交暂存区与工作目录均保持原样。适合只想“撤销提交动作”但保留所有更改并重新组织提交的情况。--hard 模式彻底丢弃更改不仅重置暂存区还会把工作目录中的所有更改回退到目标提交目标提交之后的更改被彻底丢弃git reset --hard--hard模式表示 Git 会同时撤销工作目录中的所有改动。例如git reset --hard HEAD~2会将当前分支回退两个提交点同时撤销你所做的所有更改并将这两个提交从项目历史中移除。只有当你确定想彻底丢弃本地的所有开发内容时才应该使用--hard。而且如果你已经将提交推送到了共享仓库请不要执行git reset --hard因为这将对仓库中的其他人造成问题。仓库中 重置一个分支resetting-a-branch 还展示了带--hard标志的跨分支重置用法git reset stage master --hard该命令将stage分支重置为与master完全相同--hard用于忽略重置之前或之后被暂存的所有更改。在某些工业场景下删除分支可能干扰或破坏 CI/CD 流水线此时用git reset重置分支比删除重建更安全。安全清单何时用 reset何时用 revert场景推荐命令说明本地提交错误尚未推送git reset hash直接移动分支指针历史干净误将文件加入暂存区git reset 文件名仅取消暂存保留文件更改本地实验彻底失控git reset --hard hash彻底丢弃更改需谨慎提交已推送至共享仓库git revert hash通过反向提交安全撤销不破坏他人历史想调整上一个提交内容git commit --amend修改最近一次提交详见 修改提交amending-a-commit一句话总结reset 面向本地历史revert 面向远程历史。在像 first-contributions 这样的开源协作场景中你的分支最终要通过 Pull Request 合入上游因此凡是对已经推送的提交做历史改写操作都应优先考虑 revert 而非 reset。参考文档重置一个提交英文原文撤销本地提交undoing-a-commit撤销一个提交reverting-a-commit重置一个分支resetting-a-branch修改提交amending-a-commit附加资料索引【免费下载链接】first-contributions✨ Help beginners to contribute to open source projects项目地址: https://gitcode.com/gh_mirrors/fi/first-contributions创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考