You are here
Git版本恢复命令reset
reset命令有3种方式：
1：git reset –mixed：此为默认方式，不带任何参数的git reset，即时这种方式，它回退到某个版本，只保留源码，回退commit和index信息
2：git reset –soft：回退到某个版本，只回退了commit的信息，不会恢复到index file一级。如果还要提交，直接commit即可
3：git reset –hard：彻底回退到某个版本，本地的源码也会变为上一个版本的内容
1 2 3 4 5 6 7 8 9 10 11 12 | #回退所有内容到上一个版本 git reset HEAD^ #回退a.py这个文件的版本到上一个版本 git reset HEAD^ a.py #向前回退到第3个版本 git reset –-soft HEAD~3#将本地的状态回退到和远程的一样 git reset –-hard origin/master #回退到某个版本 git reset 057d #回退到上一次提交的状态，按照某一次的commit完全反向的进行一次commit git revert HEAD |
如果我们某次修改了某些内容，并且已经commit到本地仓库，而且已经push到远程仓库了
这种情况下，我们想把本地和远程仓库都回退到某个版本，该怎么做呢？
前面讲到的git reset只是在本地仓库中回退版本，而远程仓库的版本不会变化
这样，即时本地reset了，但如果再git pull，那么，远程仓库的内容又会和本地之前版本的内容进行merge
这并不是我们想要的东西，这时可以有2种办法来解决这个问题：
1：直接在远程server的仓库目录下，执行git reset –soft 10efa来回退。注意：在远程不能使用mixed或hard参数
2：在本地直接把远程的master分支给删除，然后再把reset后的分支内容给push上去，如下：
#新建old_master分支做备份
git branch old_master
#push到远程
git push origin old_master:old_master
#本地仓库回退到某个版本
git reset –hard bae168
#删除远程的master分支
git push origin :master
#重新创建master分支
git push origin master
在删除远程master分支时，可能会有问题，见下：
$ git push origin :master error: By default, deleting the current branch is denied, because the next error: 'git clone' won't result in any file checked out, causing confusion. error: error: You can set 'receive.denyDeleteCurrent' configuration variable to error: 'warn' or 'ignore' in the remote repository to allow deleting the error: current branch, with or without a warning message. error: error: To squelch this message, you can set it to 'refuse'. error: refusing to delete the current branch: refs/heads/master To git@xx.sohu.com:gitosis_test ! [remote rejected] master (deletion of the current branch prohibited) error: failed to push some refs to 'git@xx.sohu.com:gitosis_test'
这时需要在远程仓库目录下，设置git的receive.denyDeleteCurrent参数
git receive.denyDeleteCurrent warn
然后，就可以删除远程的master分支了
虽然说有以上2种方法可以回退远程分支的版本，但这2种方式，都挺危险的，需要谨慎操作……
来自 http://www.cnblogs.com/0616--ataozhijia/p/3644482.html
git reset soft,hard,mixed之区别深解
标签：class style log com 使用 src http it 文件
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了。
- 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
- 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命令了
3.mixed(default）
--mixed是reset的默认参数，也就是当你不指定任何参数时的参数。它将重置HEAD到另外一个commit,并且重置index以便和HEAD比配，但是也到此为止。working copy不会被更改。所以所有从original HEAD到你重置到的那个commit之间的所有变更仍然保存在working copy中，被标示为已变更，但是并未staged的状态
【转】git reset 之 soft mixed hard选项的区别
(2014-09-09 16:54:06)以下为转发的正文
The reset command. Confusing. Misunderstood. Misused. But it doesn’t need to be that way! It’s really not too confusing once you figure out what’s going on.
Definitions
首先，让我们来解释几个定义.
First, let’s define a few terms.
HEAD（头）
指向当前branch最顶端的一个commit，该分支上一次commit后的节点
This is an alias for the tip of the current branch, which is the most recent commit you have made to that branch.
Index（索引）
The index, 也可以被认为是staging area（暂存区）, 是一堆将在下一次commit中提交的文件，提交之后它就是 HEAD的父节点. （译注：git add添加的文件）
The index, also known as the staging area, is the set of files that will become the next commit. It is also the commit that will become HEAD’s parent.
Working Copy（工作副本）
当前工作目录下的文件，（译注：一般指，有修改，没有git add，没有git commit的文件）
This is the term for the current set of files you’re working on in your file system.
Flow（流程如下）
当你第一次checkout一个新的分支，HEAD指向该分支上最近一次commit。它和index和working copy是一样一样的。
When you first checkout a branch, HEAD points to the most recent commit in the branch. The files in the HEAD (they aren’t technically files, they’re blobs but for the purposes of this discussion we can think of them as straight files) match that of the files in the index, and the files checked out in your working copy match HEAD and the index as well. All 3 are in an equal state, and Git is happy.
当你修改了一个文件，Git注意到了会说“哦，有些东西被改了”，你的working copy不再和index和HEAD相同了，所以当文件有改动，它会标记这些文件。
When you perform a modification to a file, Git notices and says “oh, hey, something has changed. Your working copy no longer matches the index and HEAD.” So it marks the file as changed.
然后，你执行git add命令，这条命令会将上面修改的文件缓存在index中，Git又说了“哦，你的working copy和index相同了，而他们俩和HEAD不同了”。
Then, when you do a git add, it stages the file in the index, and Git says “oh, okay, now your working copy and index match, but those are both different than HEAD.”
当你执行git commit，Git创建了一个新的commit，HEAD这时指向这个新的commit，此时，HEAD & index & working copy又相同了，Git又开心了一次。
When you then perform a git commit, Git creates a new commit that HEAD now points to and the status of the index and working copy match it so Git’s happy once more.
Reset
If you just look at the reset command by itself, all it does is reset HEAD (the tip of the current branch) to another commit. For instance, say we have a branch (the name doesn’t matter, so let’s call this one “super-duper-feature”) and it looks like so:
If we perform:
> git reset HEAD… nothing happens. This is because we tell git to reset this branch to HEAD, which is where it already is. But if we do:
> git reset HEAD~1(HEAD~1 is shorthand case for “the commit right before HEAD”, or put differently “HEAD’s parent”) our branch now looks like so:
If we start at the latest commit again and do:
> git reset HEAD~2our branch would look like so:
Again, all it does on a basic level is move HEAD to another commit.
Parameters
reset命令本身很简单，但是它的参数让人迷惑，主要的参数有soft, hard and mixed，它们告诉Git，当执行reset时，要对index和working copy做什么。
So the reset command itself is pretty simple, but it’s the parameters that cause confusion. The main parameters are soft, hard and mixed. These tell Git what to do with your index and working copy when performing the reset.
Soft
The --soft参数只告诉Git将其他的commit重置到HEAD，就仅此而已。index和working copy中的文件都不改变。
parameter tells Git to reset HEAD to another commit, but that’s it. If you specify --soft Git will stop there and nothing else will change. What this means is that the index and working copy don’t get touched, so all of the files that changed between the original HEAD and the commit you reset to appear to be staged.
Mixed (default)
The --mixed 改变HEAD和index，指向那个你要reset到的commit上。而working copy文件不被改变。当然会显示工作目录下有修改，但没有缓存到index中。
parameter (which is the default if you don’t specify anything) will reset HEAD to another commit, andwill reset the index to match it, but will stop there. The working copy will not be touched. So, all of the changes between the original HEAD and the commit you reset to are still in the working copy and appear as modified, but not staged.
Hard
The --hard HEAD & index & working copy同时改变到你要reset到的那个commit上。这个参数很危险，执行了它，你的本地修改可能就丢失了。
parameter will blow out everything – it resets HEAD back to another commit, resets the index to match it, and resets the working copy to match it as well. This is the more dangerous of the commands and is where you can cause damage. Data might get lost here*!
可以用git reflog命令查看coomit ID，恢复到reset之前的状态。
* You can recover it using
git reflog but that’s out of scope here.转自：http://davidzych.com/2014/05/24/difference-between-git-reset-soft-mixed-and-hard/