git 我提交了,但我又后悔了

背景

在实际的开发工作中,使用git commit 总会遇到一些令人抓狂的提交,一切源于手欠和脑子不清醒,把一些不该提交的东西一起提交了。
在这里插入图片描述

不过还在Git还是能给我们后悔的机会。

场景模拟

    @PostMapping("/hhh")
    public String  test1(){
        AbsBatch batch = mapper.selectByPrimaryKey("dd");
        return  batch.toString();
    }

    @PostMapping("/hhhh")
    public String  test3(){
        AbsBatch batch = mapper.selectByPrimaryKey("dd");
        return  batch.toString();
    }

在这一次的提交中,我本来只需要提交test1这个方法,但是一不小心把test3也一起提交了o((⊙﹏⊙))o

case 1 已提交未push

这种情况处理起来比较简单。如果你适用的开发工具是idea时,就显得尤为简单。

undo commit

直接就是 右键 -> undo commit
在这里插入图片描述
直接把本地的git提交记录给去掉了,但是你之前对代码的修改还在(✪ω✪) 然后你就可以回到未提交的状态,然后重新提交。

reset

git reset --soft,–hard的区别

git reset 命令可以将当前的HEAD重置到特定的状态。
首先要搞清楚下面几个概念

  • HEAD: HEAD就是指向当前分支当前版本的游标
  • Index: Index即为暂存区,当你修改了你的git仓库里的一个文件时,这些变化一开始是unstaged状态,为了提交这些修改,你需要使用git add把它加入到index,使它成为staged状态。当你提交一个commit时,index里面的修改被提交。
  • working tree: 即当前的工作目录。

git reset 的用法
git reset [<mode>] [<commit>]
git reset 将当前分支的HEAD指向给定的版本,并根据模式的不同决定是否修改index和working tree。
常用的有三种模式,–soft, --mixed, --hard,如果没有给出则默认是–mixed

1 --soft

已经有未提交的更改:如果在执行软重置之前有未提交的更改,Git 可能会拒绝执行软重置操作。您可以通过提交或保存当前工作目录中的更改来解决此问题。
请一定注意这个

reset --soft相当于后悔药,给你重新改过的机会。对于上面的场景,就可以再次修改重新提交,保持干净的 commit 记录。

以上说的是还未 push 的commit。对于已经 push 的 commit,也可以使用该命令,不过再次 push 时,由于远程分支和本地分支有差异,需要强制推送git push -f来覆盖被 reset 的 commit。

还有一点需要注意,在reset --soft指定 commit 号时,会将该 commit 到最近一次 commit 的所有修改内容全部恢复,而不是只针对该 commit。
使用 --soft参数将会仅仅重置HEAD到制定的版本,不会修改index和working tree

三次提交
第一次:test1.txt
第二次:test2.txt
第三次:test3.txt

在这里插入图片描述在这里插入图片描述
本地文件的内容并没有发生变化,而index中仍然有最近一次提交的修改,这时执行git status会显示这些修改已经在再暂存区中了,无需再一次执行git add。接下来就可以重新修改提交了。

2 --mixed

使用 --mixed参数与 --soft的不同之处在于, --mixed修改了index,使其与第二个版本匹配。index中给定commit之后的修改被unstaged。需要重新 git add .
在这里插入图片描述

3. --hard

使用–hard同时也会修改working tree,也就是当前的工作目录,如果我们执行git reset --hard HEAD~,那么最后一次提交的修改,包括本地文件的修改都会被清楚,彻底还原到上一次提交的状态且无法找回。所以在执行reset --hard之前一定要小心
不建议使用!

revert

如果你比较莽,直接就是一个revert commit,你就会悲催的发现:代码确实回退了,但是你的代码全部都不见了!!!∑(゚Д゚ノ)ノ 。如果你打算重写,那我只能表示:人山人海雅座一位!
想要你的代码回来,也有那么几种方法

  • 对 revert的这次提交再次进行revert or undo commit

但是呢,这里有个问题就是,重新revert找回的代码,额,提交不了。这时候你本地的代码和Git云上的代码就出现了不一致。我的建议:新建一个项目重新拉代码,那那个新项目里修改。

在这里插入图片描述

  • 查看git的提交记录,然后自己复制粘贴去(不推荐)
    在这里插入图片描述

case 2 commit and push

如果你跟我一样,就喜欢直接一步到位。每次都是提交和push一起操作的,那么这个过程就会麻烦不少。

处理

  1. 确保您的工作目录干净,并且没有未提交的更改。您可以使用git status命令检查当前工作目录的状态。

  2. 使用git log命令查看提交历史,并找到您想要重新提交的上次提交的哈希值(commit hash)。
    要查看上次提交的哈希值,您可以使用以下命令:

    git log --oneline
    

    这将显示最近的提交记录,每个提交记录都有一个简短的哈希值以及提交的摘要信息。最近的提交记录将显示在顶部。
    在这里插入图片描述

    如果您只想查看最近一次提交的哈希值,您可以使用以下命令:

    git log --oneline -n 1
    

    这将只显示最近一次提交的哈希值和摘要信息。

    请注意,哈希值是一串字符,通常由16进制数字组成。您可以使用这个哈希值来标识和引用特定的提交。

  3. 运行以下命令,将您想要重新提交的上次提交的部分内容添加到暂存区:

    git cherry-pick <commit-hash>
    

    <commit-hash>替换为您要重新提交的上次提交的哈希值。

    这将应用指定的提交,并将更改添加到暂存区。

  4. 运行以下命令,检查您的更改是否正确添加到暂存区:

    git status
    
    
    确保您只看到了您想要重新提交的部分内容被添加到了暂存区。
    
  5. 运行以下命令,提交您的更改:

    git commit -m "Recommit specific changes from previous commit"
    
    
    
    替换提交信息`"Recommit specific changes from previous commit"`为您自己的提交信息。
    
    这将创建一个新的提交,包含您重新提交的部分内容。
    
  6. 最后,如果您需要将更改推送到远程仓库,请运行:

    git push
    

    这将把您的新提交推送到远程仓库。
    请注意,git cherry-pick命令会将指定提交中的更改复制到当前分支,因此请确保您在正确的分支上进行操作。

### 如何恢复Git中未提交但已重置的更改 当在 Git 中进行了未提交的工作,却意外执行了 `reset HEAD` 或其他导致工作目录丢失的操作时,可以尝试以下方法来尽可能恢复这些改动。 #### 利用IDEA内置功能找回未提交变更 对于使用 IntelliJ IDEA 的开发者来说,在 IDE 内部进行版本控制系统操作时,如果发生误操作如重置 HEAD 导致未保存的内容消失,那么可以通过IDE本身的特性来找回数据。IDE会缓存一段时间内的编辑历史记录,即使没有被正式加入到 Git 版本库中也可以通过如下方式访问: 1. 打开菜单栏中的 VCS -> Local History -> Show History; 2. 浏览不同时间点的状态差异,寻找最后一次有效修改前的时间戳; 3. 右键点击目标条目并选择 Revert Selected Changes 来应用选定的历史版本至当前项目环境; 这种方法适用于那些依赖于特定开发工具来进行日常编码工作的场景,并且仅限于支持此特性的集成开发环境中实现[^2]。 #### 使用Reflog查找最近的动作 即便是在命令行环境下,只要还没有清理 reflog(默认情况下至少保持90天),就可以利用它去追踪所有发生在分支上的变动,包括那些未曾公开发布的内部转移动作。具体做法为运行 `git reflog` 查看日志列表,从中定位到最接近的一次正常状态对应的哈希值,再借助 `checkout` 或者 `reset` 命令返回那个时刻。 ```bash $ git reflog ... <hash>... (HEAD@{n}) HEAD@{m}: commit: Your last real commit message here. ``` 一旦找到了合适的 `<hash>` ,则可以根据实际情况决定是要创建新的分支还是直接切换回去继续工作: ```bash # 创建新分支以保护现有进度 $ git checkout -b recovery_branch <hash> # 或者强行回到过去某个确切位置(谨慎行事!) $ git reset --hard <hash> ``` 需要注意的是,上述两种方案都假定用户处于单个工作副本之中并未推送到远端服务器上造成更大范围的影响。另外,由于涉及到潜在的数据风险,建议先复制一份完整的工程备份后再做任何大胆尝试[^4]。 #### 处理暂存区外丢失的文件更动 针对已经添加到了索引/暂存区(`staging area`)内却被移除的情况,比如通过 `git rm --cached <file>` 移除了跟踪文件却又后悔了的情形下,可采用下面的方法快速修正: 假设有一个名为 `test01` 的文本文件经历了一系列不必要的改变并且已被标记准备纳入下次提交的一部分,现在希望取消这部分更新而让其回归到最后一次确认过的模样而不影响其它部分的话,应该这样做: ```bash echo "change which should be removed later" > test01 git add test01 git reset HEAD test01 # 这一步使得test01从暂存区回到了工作树中,但是不会删除实际存在的文件内容 ``` 此时虽然看起来好像什么都没变,但实际上已经成功阻止了即将发生的错误提交行为,同时也保留住了原始文档里的全部信息以便后续调整[^3]。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值