git_文件版本回滚/撤销修改(undo modified/undo add/undo commit)(git version:＞1.8.2)(2021.10)

文章目录

• • Working tree directory, staging area, and Git directory
• target for undo operations
• undo modified (undo woking directory modification)(level1)
• undo add(level2)
• • git reset
  • 文件版本(工作空间)内容回退
  • • git reset --hard
    • git checkout
    • git reset 示例
  • git rm --cached
• undo commit
• • 示例
  • • 撤销最近一次commit
    • git reset --mixed
  • 我这里有个例子
  • • 查看提交情况:
    • 撤销commit
    • 恢复到暂存区(可指定恢复的对象)
    • 恢复到工作空间
    • 检测(revision)分支流
• 指定文件版本回滚
• 使用reset后push 时注意

git 的新版本发生些许变化,这使得git help reset上的内容可能发生了变化
在了解相关命令和做法前,建议您先了解git管理下的文件的三种状态:

Working tree directory, staging area, and Git directory

target for undo operations

做撤销的行为一般是由于不小心将当前文件改乱了,进而想让工作区中的文件恢复到被修改之前.

undo modified (undo woking directory modification)(level1)

当工作区workspace中的内容尚未add 到index时,您可以将index区中的内容调出来覆盖掉当前工作区的文件内容
如果是这样,用check命令即可(撤销workspace中的修改)
git checkout fileName
一般来说,这个命令很够用了,一般我们没有完成一定程度的修改,是不会add到staging area中的.(而且,在把文件改乱了又返回的时候都还处在这个阶段)

undo add(level2)

git reset

• 但如果您不小心将working space 中尚未完善的修改add到了staging area,那么可以针对对某个文件利用git reset [HEAD] fileName/directory来撤销add 操作(该操作并不影响到工作空间中的文件,单纯地回到add之前的状态)

• 换句话说,对于被改乱的文件似乎还是无能为力.(单纯undo add 还改变不到工作区,您需要使用(checkout/git reset --hard选项)来恢复工作空间中的文件(目录)到之前的某个版本

文件版本(工作空间)内容回退

git reset --hard

• (如果使用git reset --hard <commitID>那么是从已归档的repository区中读取文件并覆盖工作目录 )

git checkout

• 如果是使用checkout <file/dir> 可以从暂存区staging area回退到之前的上次执行add操作时所保留的版本

注意,git reset& git reset --soft &git reset --hard三者功能并不相同,查看help 手册!
回退操作完成之后,使用git status 以及 git log --graph(或者显示的紧凑版本: git log --all --decorate --oneline --graph)可以检查操作结果

• 撤销被提交到staging area 中的修改:

git reset 示例

先检查当前环境

执行git reset --soft 5920,观察HEAD指针的变化

git rm --cached

git rm --cached <itemName>或许也能解决undo add 的需求

undo commit

git reset --soft <commit_id>

(通过移动HEAD指针实现),--soft 比--hard安全(温和)
但是这样依然作用不到working area
即,被改乱的文件还是得不到恢复

示例

撤销最近一次commit

• 检查环境
  
• 执行git reset --soft
  
• 用reflag 检查
  

git reset --mixed

一样不变动working area

• git reset --hard <commit_id>能够恢复工作区的文件
  但是没指定文件的话会误伤其他文件的
• 对于git reset

• 我这里有个例子

  • 查看提交情况:

  • 操作之前的:

撤销commit

• • 撤销指定对象(文件/目录下所有文件)的指定commit节点到指定版本(commit id)
  • 例如,我们将commit 节点回滚到1843...;并使用git log查看
  • 

恢复到暂存区(可指定恢复的对象)

• • 将此时commit中的内容恢复到暂存区(将暂存区的未提交修改丢弃,接受repository 中commit恢复出来的代码)(这个时候不指定commit id,但可以指定(dir/file))

  • 可以恢复指定的目录/文件

  • 

恢复到工作空间

• 将指定目录(文件)从暂存区中恢复到工作空间(原有内容(修改)将被丢弃)
• 

检测(revision)分支流

• (情况说明,此时有两个分支(main&fzh)

  • 由于发生了冲突,我通过reset --soft 撤销了本地的落后的修改的commit,打算直接采用远程分支的修改,来简单处理冲突
  • 在合并分支的时候:git merge origin/otherBranchName&git merge otherBranchName未必一致,所以有时您需要都执行变(特别是在本地也创建了对应的otherBranchName分支)

  • 目录->文件:变通方法:即给目录后面加*(通配符),也可以达到一定的批量reset效果

  • 再从暂存区中重设工作区中的内容(git checkout <file/directory>)) ;
    • 至此,工作区中的(指定文件/目录)内容就会被重置,修改就会被丢弃
  • 如果,直接使用reset --hard可以直接修改工作区中的内容,但是reset --hard,比reset --soft 来的危险;
  • 我们可以分步,手动操作(中途可以检测分支流的走势)

  • 我认为,git merge branchName 这一操作应该只关注于commit的节点上的代码,如果您本地的修改还未commit,那么在合并你当前的节点分叉出去的分支因该是不会有冲突提示的,但是当你想要在合并之后提交的时候,就是冲突可能来临的时候

• (可学上网)(但是参考git help reset文档也不错)
  参考链接

指定文件版本回滚

实用性强的checkout
您可以像这样回滚某个文件到早些版本
git checkout <commit_id> fileName
可以先利用git log fileName来查询某个文件的历史版本(提案在commit号),然后将其回滚

可以看到HEAD指针是不变的,但是文件版本回滚了(内容回滚)
当然其他文件不会受到影响
参考链接

使用reset后push 时注意

当您在本地使用git reset 后,如果想要push到远程仓库,那么就需要使用–force参数进行强制push(否则会因为您的分支落后于远程仓库而push 不上去
(当然,如果您使用reset --hard 回到的commit_id 领先于或者持平于远程仓库,这时候您还是可以直接push,而不需要采用–force参数.