git reset soft,hard,mixed之区别深解

git reset --hard  强制更新覆盖本地


 

GIT reset命令,似乎让人很迷惑,以至于误解,误用。但是事实上不应该如此难以理解,只要你理解到这个命令究竟在干什么。

首先我们来看几个术语

  • HEAD

这是当前分支版本顶端的别名,也就是在当前分支你最近的一个提交

  • Index

index也被称为staging area,是指一整套即将被下一个提交的文件集合。他也是将成为HEAD的父亲的那个commit

  • Working Copy

working copy代表你正在工作的那个文件集

  • Flow

当你第一次checkout一个分支,HEAD就指向当前分支的最近一个commit。在HEAD中的文件集(实际上他们从技术上不是文件,他们是blobs(一团),但是为了讨论的方便我们就简化认为他们就是一些文件)和在index中的文件集是相同的,在working copy的文件集和HEAD,INDEX中的文件集是完全相同的。所有三者(HEAD,INDEX(STAGING),WORKING COPY)都是相同的状态,GIT很happy。

当你对一个文件执行一次修改,Git感知到了这个修改,并且说:“嘿,文件已经变更了!你的working copy不再和index,head相同!”,随后GIT标记这个文件是修改过的。

然后,当你执行一个git add,它就stages the file in the index,并且GIT说:“嘿,OK,现在你的working copy和index区是相同的,但是他们和HEAD区是不同的!”

当你执行一个git commit,GIT就创建一个新的commit,随后HEAD就指向这个新的commit,而index,working copy的状态和HEAD就又完全匹配相同了,GIT又一次HAPPY了。

下面这一段是另外一个牛人的解释:

总的来说,git reset命令是用来将当前branch重置到另外一个commit的,而这个动作可能会将index以及work tree同样影响。比如如果你的master branch(当前checked out)是下面这个样子:

- A - B - C (HEAD, master)

HEAD和master branch tip是在一起的,而你希望将master指向到B,而不是C,那么你执行

git reset B以便移动master branch到B那个commit:

- A - B (HEAD, master)      # - C is still here, but there's no branch pointing to it anymore

注意:git reset和checkout是不一样的。如果你运行git checkout B,那么你讲得到:

- A - B (HEAD) - C (master)

这时HEAD和master branch就不在一个点上了,你进入detached HEAD STATE. HEAD,work tree,index都指向了B,但是master branch却依然指向C。如果在这个点上,你执行一个新的commit D,那么你讲得到下面(当然这可能并不是你想要的,你可能想要的是创一个branch做bug fix):

- A - B - C (master)
\
D (HEAD)

记住git reset不会产生commits,它仅仅更新一个branch(branch本身就是一个指向一个commit的指针)指向另外一个commit(Head和branch Tip同时移动保持一致).其他的仅剩对于index和work tree(working directory)有什么影响。git checkout xxxCommit则只影响HEAD,如果xxxCommit和一个branch tip是一致的话,则HEAD和branch相匹配,如果xxxCommit并不和任何branch tip相一致,则git进入detached HEAD 状态

  • Reset

如果你仔细研究reset命令本身就知道,它本身做的事情就是重置HEAD(当前分支的版本顶端)到另外一个commit。假设我们有一个分支(名称本身无所谓,所以我们就简单称为"super-duper-feature”分支吧),图形化表示如下:

如果我们执行:

git reset HEAD

任何事情都不会发生,这是因为我们告诉GIT重置这个分支到HEAD,而这个正是它现在所在的位置。

git reset HEAD~1

当我们再执行上面的命令时(HEAD~1是“the commit right before HEAD”的别名,或者说:put differently "HEAD's parent"),我们的分支将会如下所示

如果我们执行git reset HEAD~2,则意味着将HEAD从顶端的commit往下移动两个更早的commit。

  • Parameters
  1. soft

--soft参数告诉Git重置HEAD到另外一个commit,但也到此为止。如果你指定--soft参数,Git将停止在那里而什么也不会根本变化。这意味着index,working copy都不会做任何变化,所有的在original HEAD和你重置到的那个commit之间的所有变更集都放在stage(index)区域中。

  2.hard

--hard参数将会blow out everything.它将重置HEAD返回到另外一个commit(取决于~12的参数),重置index以便反映HEAD的变化,并且重置working copy也使得其完全匹配起来。这是一个比较危险的动作,具有破坏性,数据因此可能会丢失!如果真是发生了数据丢失又希望找回来,那么只有使用:git reflog命令了。makes everything match the commit you have reset to.你的所有本地修改将丢失。如果我们希望彻底丢掉本地修改但是又不希望更改branch所指向的commit,则执行git reset --hard = git reset --hard HEAD. i.e. don't change the branch but get rid of all local changes.另外一个场景是简单地移动branch从一个到另一个commit而保持index/work区域同步。这将确实令你丢失你的工作,因为它将修改你的work tree!

  3.mixed(default)

--mixed是reset的默认参数,也就是当你不指定任何参数时的参数。它将重置HEAD到另外一个commit,并且重置index以便和HEAD相匹配,但是也到此为止。working copy不会被更改。所有该branch上从original HEAD(commit)到你重置到的那个commit之间的所有变更将作为local modifications保存在working area中,(被标示为local modification or untracked via git status),但是并未staged的状态,你可以重新检视然后再做修改和commit

git 本地代码冲突解决,强制更新的更多相关文章

  1. 转:git合并冲突解决方法

    git合并冲突解决方法 1.git merge冲突了,根据提示找到冲突的文件,解决冲突 如果文件有冲突,那么会有类似的标记 2.修改完之后,执行git add 冲突文件名 3.git commit注意 ...

  2. Git二进制文件冲突解决

    Git二进制文件冲突解决 在我们合并分支的时候,如果两个分支都进行了修改那么就会产生合并冲突.对于非二进制文件的冲突解决,git会给出冲突的位置我们可以手动修改然后再commit.但是对于非二进制文件 ...

  3. Git 二进制文件冲突解决

    Git 二进制文件冲突解决 在我们合并分支的时候,如果两个分支都进行了修改那么就会产生合并冲突.对于非二进制文件的冲突解决,git会给出冲突的位置我们可以手动修改然后再commit.但是对于非二进制文 ...

  4. Git - 可视化冲突解决工具P4Merge

    P4Merge P4Merge是Git的一个第三发Diff和Merge工具(可视化冲突解决工具). 下载地址: https://www.perforce.com/downloads/visual-me ...

  5. git合并冲突解决方法

    1.git merge冲突了,根据提示找到冲突的文件,解决冲突 如果文件有冲突,那么会有类似的标记 2.修改完之后,执行git add 冲突文件名 3.git commit 注意:没有-m选项 进去类 ...

  6. Git的冲突解决过程

    下面图是我总结一次提交遇到冲突解决的过程. 1. 把本地工作区的修改提交到本地仓库 2. 从远程仓库拉取代码,与本地仓库合并(pull = fetch + merge) 3. 本地仓库的代码推送回工作 ...

  7. git pull 冲突解决

    这个意思是说更新下来的内容和本地修改的内容有冲突,先提交你的改变或者先将本地修改暂时存储起来. 处理的方式非常简单,主要是使用git stash命令进行处理,分成以下几个步骤进行处理. 1.先将本地修 ...

  8. git push冲突解决

    1. 首先,可以试图用git push origin branch-name推送自己的修改:2. 如果推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并:如果git pull提示 ...

  9. git pull冲突解决

    场景:用户UserA修改了文件File1,用户UserB也修改了文件File1并成功merge到了服务器上,而UserA和UserB改动了同一个代码块,当UserA拉取代码时git无法merge此改动 ...

随机推荐

  1. kerberos环境storm配置:Running Apache Storm Securely

    Running Apache Storm Securely Apache Storm offers a range of configuration options when trying to se ...

  2. 使用正则替换script及其内容

    因做微信公众号文章保存,发现他的js大多数也用不着,所以就想着用正则替换掉源代码中的js片段 正则代码: <script(?:[^<]++|<(?!/script>))*+&l ...

  3. ubuntu-18.04 设置开机启动脚本-亲测有效

    ubuntu-18.04不能像ubuntu14一样通过编辑rc.local来设置开机启动脚本,通过下列简单设置后,可以使rc.local重新发挥作用. 2.将下列内容复制进rc-local.servi ...

  4. Centos扩容swap分区

    今天在vps上装了个msf,装了一半竟然被kill掉了,因为RAM只有512M,swap也只有130M.遂到网上寻求解决办法,下面是我的笔记: 查看当前swap大小: free -h 修改swap大小 ...

  5. 我的2018OKR年终回顾与2019OKR初步规划

    转眼一年又过去了,在这个年底的时候,按照国际惯例,又到了重新回顾审视一下这一年来的得失,规划一下明年的奋斗方向的时候了.因此,我继续使用OKR来给自己做Review和Planning,也希望自己能够保 ...

  6. ACache【轻量级的开源缓存框架】

    版权声明:本文为HaiyuKing原创文章,转载请注明出处! 前言 官方介绍 ASimpleCache 是一个为android制定的 轻量级的 开源缓存框架.轻量到只有一个java文件(由十几个类精简 ...

  7. Docker Swarm搭建多服务器下Docker集群

    对于有多台服务器来讲,如果每一台都去手动操控,那将会是一件非常浪费时间的事情,毕竟时间这东西,于我们而言,十分宝贵,或许在开始搭建环境的时候耗费点时间,感觉是正常的,我也如此,花费大堆时间在采坑和填坑 ...

  8. Springboot整合Elastic-Job(二)

    上文我们讲到Springboot整合Elastic-Job整合的demo,只是简单的实现了主要功能.本文在上文基础上,进行新的调整. 事件追踪 Elastic-Job提供了事件追踪功能,可通过事件订阅 ...

  9. 【大数据安全】Kerberos集群安装配置

    1. 概述 Kerberos是一种计算机网络认证协议,它允许某实体在非安全网络环境下通信,向另一个实体以一种安全的方式证明自己的身份.它也指由麻省理工实现此协议,并发布的一套免费软件.它的设计主要针对 ...

  10. 【1】Asp.Net Core2.2从环境配置到应用建立

    作者:Eleven 来源:公众号[软谋net] [前言] .Net Core开源&跨平台,已经肉眼可见将成为.Net平台的未来,在企业招聘需求上已经频频见到,接触到很多公司内部都已经开始尝试C ...