我的更改在git重置后消失了--soft和git checkout。他们去哪里了？ - 腾讯云开发者社区

文章/答案/技术大牛

发布

揭秘Git高手的10个秘密武器：让你的工作效率飙升！

可以使用以下命令在一个步骤中完成这两个任务： git checkout -b branchName -b标志和git checkout命令一起使用，不仅允许我们创建一个新的分支，还能立即切换到它。...当你尝试使用git checkout B切换到分支B时，Git阻止了这个操作，并显示了一个错误：我们可以按照错误消息的建议提交更改。但提交更像是一个固定的时间点，并不是一个正在进行中的工作。...在下面的截图中，高亮的部分代表你可以轻松复制的提交哈希值： 10、重置Git提交假设你对项目进行了提交。然而，在检查后，你意识到需要调整或完全撤销最后一次提交。...对于这种情况，Git提供了这些强大的命令。软重置： git reset --soft HEAD^ 当使用git reset --soft HEAD^时，执行一个软重置。...混合重置： git reset --mixed HEAD^ 这是当你不指定--soft或--hard时使用git reset HEAD^的默认行为。它撤销了最后的提交，并从暂存区中移除了它的更改。

9791 0

如何将已经执行的修改操作撤销

根据你的改动所处的“阶段”（在工作区、暂存区还是已经提交到了版本库），撤销修改的方法是不同的。撤销修改：根据“修改在哪里”选择方法 Git 非常灵活，它允许你在不同的阶段撤销修改。...这时，Git 为我们提供了更方便的“撤销”方法。...它的原理： git checkout -- [文件名] 命令的意义是：“Git，请你用暂存区（如果文件在暂存区有改动）或版本库中当前分支最新提交（如果文件不在暂存区）的那个版本的文件，来覆盖我工作区的当前文件...但不要改变我的工作区。” 执行这个命令后，暂存区里这个文件的改动就会被移除，回到它在最新提交时的状态。...同时，强制性地把暂存区和工作区的内容都重置为上一个版本时的状态。” 这样一来，你做的最后一次提交就从当前分支的历史中“消失”了，你的文件内容也回到了上一个提交时的状态。

6931 0

您找到你想要的搜索结果了吗？

是的

没有找到

重新搞懂Git，掌握日常命令和基本操作

它超越了Subversion，CVS，Perforce和ClearCase等SCM工具，具有廉价的本地分支，方便的暂存区域和多个工作流程等功能。 2、git&平台 git 是一个工具，是基础设施。...（--mixed、--soft、--hard、--merge），重置后不要的版本就找不回来了。...git diff head # 暂存区和版本库比较 git diff –cached git checkout checkout命令用于版本库或者暂存区域中撤销更改到工作目录，同时也可用于切换分支...为了记忆错乱避免混乱，我通常不用改操作，因为对于撤销完全可以用reset和restore，而对于分支切换可以用switch，他们从语义上来说更贴切。所以这个操作你可以不用，我也难得记！...# 把newbranch分支合并到master分支 git merge newbranch git rebase rebase 和 merge作用都是一样的，区别是rebase 没有分叉记录，他们合并后两个分支的

5006 0

原创 | 想成为Git大神？从学会reset开始吧

这是我们这个git专题的目录，如果我们执行git checkout bee9ce，那么我们的工作目录会被重置到这个提交之后的状态。...soft参数表示我们reset的时候只执行第一个步骤，也就是移动指针的步骤。 ? reset之后我们发现test.txt这个文件并没有消失，仍然还在暂存区当中，只不过还没有被commit。...第二步（更新暂存区）如果我们在reset的时候加上了--soft的参数，它会在执行第一步结束之后就退出，后面的第二步和第三步都不会执行。...虽然这些提交被取消了，但是它们对应的改动仍然存在，并且一样存放在暂存区当中，相当于执行完git add之后的状态。如果我们继续执行第二步，git会把暂存区也给重置，回到git add之前的状态。...只要是提交了的改动，即使reset了，也可以通过reflog找回来，但是如果没有提交的就没有办法了，所有的改动都会消失。对于开发者来说，这是一个巨大的打击，一定要切记慎重。

6372 0

【git系列】git命令之撤销回退篇

#撤销指定文件 git checkout -- # 撤销所有 git checkout -- . git checkout – ....你对那个文件在本地的任何修改都会消失——Git 会用最近提交的版本覆盖掉它。除非你确实清楚不想要对那个文件的本地修改了，否则请不要使用这个命令。...命令：git merge --abort commit后回退指定版本命令git reset - git reset --soft: 将分支回退到指定提交，工作区维持现状不变,暂存区会在现有基础上增加该...- git reset --hard: 将分支回退到指定分支，暂存区和工作区都会被同步为该指定的提交。 git reset后的三个参数回退程度是依次递进。...soft最轻微，它不会重置当前工作区和暂存区，只会将回退版本后续的提交加到暂存区。 mixed会改变暂存区，使它和回退版本同步。 hard会重置工作区和暂存区，使它和回退版本一致。

2K1 0

技能篇：git的简易教程

//重置到003444c7 --hard 模式重置 HEAD 在当前分支到某次 commit 时，工作目录里的新改动和已经 add 到 stage 暂存区的新改动会全都消失。...工作目录（workspace）、暂存区（index/stage）及本地仓库（repository）重置成目标 commit 的內容，所以效果看起来等同于清空暂存区和工作区 --soft 模式 --soft...模式在重置 HEAD 时，会保留工作目录和暂存区中的内容，并把重置 HEAD 所带来的新的差异放进暂存区，保留工作目录（workspace）和暂存区（index/stage）的内容，只让 repository...在这种情况，Git会停止rebase并会让你去解决冲突；在解决完冲突后，用 git add 命令去更新这些内容的索引(index), 然后，你无需执行 git-commit,只要执行git rebase...所以，两者的区别决定了使用方式，改动代码用 branch，不改动只查看用 tag 创建 tag 是基于本地分支的 commit，而且与分支的推送是两回事，就是说分支已经推送到远程了，但是 tag 并没有

7483 0

Git Pro深入浅出（二）

（2）修改多个提交信息为了修改在提交历史中较远的提交，必须使用更复杂的工具。Git没有一个改变历史工具，但是可以使用变基工具来变基一系列提交。...重置揭密（1）三棵树理解reset和checkout的最简方法，就是以Git的思维框架（将其作为内容管理器）来管理三棵不同的树。...# 显示了 HEAD 快照实际的目录列表 $ git cat-file -p HEAD Index：索引是你的“预期的下一次提交”–“暂存区域”，运行git add后，代码就进入“暂存区域”。...–soft：index和working directory中的内容不作任何改变，仅仅把HEAD指向。...$ git status ? 说明：第二次提交的test2被重置到了初始状态（上述示例为“Untracked”）！HEAD指针重新指向了第一次提交的commitID。

1.5K3 1

【Git版本控制器】第三弹——版本回退，撤销修改，删除文件

1.2git reset命令命令基本格式： git reset [--soft | --mixed | --hard] [HEAD] git reset [--soft | --mixed |...--hard] [HEAD] 选项 --soft 重置版本库保留工作区，缓存区更改 --mixed（不带参数时的默认选项）重置版本库，缓存区保留工作区更改 --hard（慎用）重置版本库，缓存区...因为如果我们在工作区进行了编写代码，如果直接用--hard，那么工作区没有进入版本库里面的代码就消失了，再也找不到了。...那么我们也不知道那个版本的commit id了呀。用HRAD^也是回退到当前master分支下的前一个版本。这时候就要用git reflog 查看每次的回退的信息了。...还有一个就是git提供的删除文件的操作。 git rm [filename] git rm [filename] 这个命令会直接把工作区和暂存区的这个文件都删除。

1.2K1 0

Git 从入坑到成神，你只需要敲一遍命令！

前几天还有网友差点和同事干起来了，原因就是代码经常莫名其妙的被“丢失”，究其原因就是 Git 用的不熟，遇到冲突后直接把人的代码给覆盖掉了，才有了后来的“翻车事故”！ Git 很简单，也很复杂。...git init 之后，我往往需要把它和远程仓库关联，则可以使用下面的命令进行关联。 ? 关联成功后，我们就可以执行 git push 推送代码了。 ? 第三个命令，git pull。...删除冲突标记后(和 >>>>>>>>>>>>>>>>>>>>的行)。解决冲突后，可以再次执行 git diff 查看冲突详情。...git reset --soft 将HEAD引用指向给定提交。索引（暂存区）和工作目录的内容是不变的，在三个命令中对现有版本库状态改动最小。...也就是在给定提交后所修改的内容都会丢失(新文件会被删除，不在工作目录中的文件恢复，未清除回收站的前提)。 ? 下面是我常用的一些重置操作。 ?

7001 0

理解 git checkout 与 git reset 的联系和区别

在日常 Git 版本控制中，git checkout 主要用于切换分支与恢复文件状态，而 git reset 则可回退提交、取消暂存并重置分支指针。...当误删或误改文件后，只想恢复该文件至最近一次提交，无需影响其它改动，用 git checkout HEAD -- path/to/file 即可。...若指定 --soft，则只移动分支指针并保留暂存区和工作区状态；指定 --hard 时则连同工作区一并重置，意味着所有未提交的改动将被丢弃。...对工作区和暂存区的影响git checkout 在默认分支切换模式下，仅更新工作区和暂存区以匹配目标提交，不会改变分支历史；在检出文件模式下，只对指定文件恢复，不动其他文件。...小结结合以上分析，可见 git checkout 与 git reset 在版本控制中各司其职却又相互补充：git checkout 更侧重环境切换与文件恢复，git reset 则专注于调整分支历史与暂存区状态

5101 0

如何在 Git 中重置、恢复，返回到以前的状态

在本文中，我们将带你了解如何去重置、恢复和完全回到以前的状态，做到这些只需要几个简单而优雅的 Git 命令。重置我们从 Git 的 reset 命令开始。...这些选项包括：hard 在仓库中去重置指向的提交，用提交的内容去填充工作目录，并重置暂存区；soft 仅重置仓库中的指针；而 mixed（默认值）将重置指针和暂存区。...实际上，它重置了（清除掉）暂存区，并用你重置的提交内容去覆盖了工作区中的内容。在你使用 hard 选项之前，一定要确保这是你真正地想要做的操作，因为这个命令会覆盖掉任何未提交的更改。...但是也要注意的是，rebase 后“原始的” C3 和 C5 仍然在那里 — 只是再没有一个分支指向它们而已。...你看到的相关命名格式，去重置任何一个东西： $ git reset HEAD@{1} 一旦你理解了当“修改”链的操作发生后，Git 是如何跟踪原始提交链的基本原理，那么在 Git 中做一些更改将不再是那么可怕的事

5.9K2 0

深入理解 git 一切皆 commit

git 入门教程推荐：简介 - Git教程 - 廖雪峰的官方网站 Git入门图文教程(1.5W字40图)—深入浅出、图文并茂 - 安木夕 - 博客园在对 git 有了基本理解和知道常规操作之后，...- Ivony的回答 - 知乎本文中的内容很少涉及工作区和暂存区的操作，有了 commit 是 git 操作的基本单位这个概念，接下来将从『一切皆 commit』来理解 git。...他们都是指向某个提交的引用（或者理解为指针）。 branch（分支）：指向你当前工作分支的最新的那个提交，当在当前分支有了新的提交，则 git 自动更新这个分支指针，以指向最新的提交。...具体来看： git reset —hard 从参数名可以猜到，这个重置方式比较“强硬”，实际上就是，将当前分支，重置到与指定引用一样的状态，丢弃在这之后的提交，以及工作区和暂存区的提交。...git reset —soft / —mixed 理解了 —hard 的含义，—soft 和 —mixed 就很好理解了，这两个参数，不会丢弃任何内容。

4000 0

经典45个git使用技巧与场合，专治不会合代码。

(main)$ git reflog 你将会看到一个你过去提交(commit)的列表, 和一个重置的提交。...我去可以通过把内容拿到你的分支里，来解决这个问题: (develop)$ git checkout solution -- file1.txt 这会把这个文件内容从分支 solution 拿到分支...如果你不准备继续在这个分支里工作, 删除这个分支的本地拷贝会更干净，使你不会陷入工作分支和一堆陈旧分支的混乱之中（IDEA 中玩转 Git）。...在这种情况下, 最好手动的查看他们的提交(commit)，并把它们拷贝到一个本地新分支，然后做提交。做完提交后, 再修改作者，参见变更作者。...你把事情搞砸了：你重置(reset) 了一些东西, 或者你合并了错误的分支, 亦或你强推了后找不到你自己的提交(commit)了。

1.9K2 0

Git 命令

] 命令描述 git reset –mixed 重置已提交和缓存区域 git reset –soft 仅仅重置已提交 git reset –hard 重置已提交、缓存区域和工作目录三棵树 Git...工作目录(Working Directory) 最后，你就有了自己的工作目录。另外两棵树以一种高效但并不直观的方式，将它们的内容存储在 .git 文件夹中。...简单的总结如下：在工作目录编辑文件； git add 后，Index 会保存并指向工作目录的修改； git commit 后，会提交新的修改，HEAD 指向改新的修改。...reset、checkout reset 命令会以特定的顺序重写这三棵树，在你指定以下选项时停止：移动 HEAD 分支的指向（若指定了 –soft，则到此停止）使索引看起来像 HEAD （若未指定...首先不同于 reset –hard，checkout 对工作目录是安全的，它会通过检查来确保不会将已更改的文件弄丢。其实它还更聪明一些。

1.1K2 0

45个 GIT 经典操作场景，专治不会合代码

(main)$ git reflog 你将会看到一个你过去提交(commit)的列表, 和一个重置的提交。...我去可以通过把内容拿到你的分支里，来解决这个问题: (develop)$ git checkout solution -- file1.txt 这会把这个文件内容从分支 solution 拿到分支 develop...如果你不准备继续在这个分支里工作, 删除这个分支的本地拷贝会更干净，使你不会陷入工作分支和一堆陈旧分支的混乱之中（IDEA 中玩转 Git）。...在这种情况下, 最好手动的查看他们的提交(commit)，并把它们拷贝到一个本地新分支，然后做提交。做完提交后, 再修改作者，参见变更作者。...你把事情搞砸了：你重置(reset) 了一些东西, 或者你合并了错误的分支, 亦或你强推了后找不到你自己的提交(commit)了。

1.6K1 0

45 个Git经典操作场景,专治不会合代码

1.1K2 0

45个 GIT 经典操作场景，专治不会合代码

(main)$ git reflog 你将会看到一个你过去提交(commit)的列表, 和一个重置的提交。...我去可以通过把内容拿到你的分支里，来解决这个问题: (develop)$ git checkout solution -- file1.txt 这会把这个文件内容从分支 solution 拿到分支 develop...如果你不准备继续在这个分支里工作, 删除这个分支的本地拷贝会更干净，使你不会陷入工作分支和一堆陈旧分支的混乱之中。...在这种情况下, 最好手动的查看他们的提交(commit)，并把它们拷贝到一个本地新分支，然后做提交。做完提交后, 再修改作者，参见变更作者。...你把事情搞砸了：你重置(reset) 了一些东西, 或者你合并了错误的分支, 亦或你强推了后找不到你自己的提交(commit)了。

2.2K4 0

headresetrevertrebase代码回滚全解：git提交记录的背后原理

本地仓库（.git）：在工作区中有个隐藏目录.git，这就是 Git 本地仓库的数据库。工作区中的项目文件实际上就是从这里签出（checkout）而得到的，修改后的内容最终提交后记录到本地仓库中。...执行以下命令回滚工作区的修改：git checkout -- build.sh不过需要特别留意的是这些改动没有提交到 Git 仓库，Git 无法追踪其历史，一旦回滚就直接丢弃了。...命令是否抹掉历史适用场景git reset是，回滚的历史将消失本地未push的记录git revert否，历史记录保留，回滚后重新生成提交记录回滚已push的内容git reset回滚某次提交确保还没其他人提交之前...，进行强制回滚——重置HEAD(当前分支的版本顶端）到另外一个commitgit reset --hard HEAD~2 git reset 代码撤回--hard 和 --soft 及默认mixed--...--soft 虽然删除了最近两个提交记录，但是还保存了提交所做的更改——告诉Git重置HEAD到另外一个commit，但也到此为止index,working copy都不会做任何变化，所有的在original

4.3K2 2

45 个 Git 操作场景，专治不会合代码

(main)$ git reflog 你将会看到一个你过去提交(commit)的列表, 和一个重置的提交。...我去可以通过把内容拿到你的分支里，来解决这个问题: (develop)$ git checkout solution -- file1.txt 这会把这个文件内容从分支 solution 拿到分支 develop...如果你不准备继续在这个分支里工作, 删除这个分支的本地拷贝会更干净，使你不会陷入工作分支和一堆陈旧分支的混乱之中。...在这种情况下, 最好手动的查看他们的提交(commit)，并把它们拷贝到一个本地新分支，然后做提交。做完提交后, 再修改作者，参见变更作者。...(setting is in seconds) 我不知道我做错了些什么你把事情搞砸了：你重置(reset) 了一些东西, 或者你合并了错误的分支, 亦或你强推了后找不到你自己的提交(commit)

1.3K1 0

Git 帮助手册

(master)$ git reflog 你将会看到一个你过去提交 (commit) 的列表，和一个重置的提交。...我去可以通过把内容拿到你的分支里，来解决这个问题: (develop)$ git checkout solution -- file1.txt 这会把这个文件内容从分支 solution 拿到分支 develop...如果你不准备继续在这个分支里工作，删除这个分支的本地拷贝会更干净，使你不会陷入工作分支和一堆陈旧分支的混乱之中。...在这种情况下，最好手动的查看他们的提交 (commit)，并把它们拷贝到一个本地新分支，然后做提交。做完提交后，再修改作者，参见变更作者。...upstream/master origin/master # 我不知道我做错了些什么你把事情搞砸了：你重置(reset) 了一些东西，或者你合并了错误的分支，亦或你强推了后找不到你自己的提交

5.3K3 0

点击加载更多

揭秘Git高手的10个秘密武器：让你的工作效率飙升！

如何将已经执行的修改操作撤销

重新搞懂Git，掌握日常命令和基本操作

原创 | 想成为Git大神？从学会reset开始吧

【git系列】git命令之撤销回退篇

技能篇：git的简易教程

Git Pro深入浅出（二）

【Git版本控制器】第三弹——版本回退，撤销修改，删除文件

Git 从入坑到成神，你只需要敲一遍命令！

理解 git checkout 与 git reset 的联系和区别

如何在 Git 中重置、恢复，返回到以前的状态

深入理解 git 一切皆 commit

经典45个git使用技巧与场合，专治不会合代码。

Git 命令

45个 GIT 经典操作场景，专治不会合代码

45 个Git经典操作场景,专治不会合代码

45个 GIT 经典操作场景，专治不会合代码

headresetrevertrebase代码回滚全解：git提交记录的背后原理

45 个 Git 操作场景，专治不会合代码

Git 帮助手册

相关资讯

热门标签

活动推荐

运营活动

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐