问几个 git 撤消的问题

同时撤销的add和commit的话 应该git reset --hard HEAD~1 就可以了

楼上+1

。。。楼上的方法会丢掉你的改动的

用 git reset HEAD~1

加 --hard 参数修改也没了

@limuxy 你这个操作会将文件弄丢的啊，楼主要求之前的修改都在，很显然去掉 --hard 参数调用这个就可以了：git reset HEAD~1

在此，强烈推荐阅读 ProGit v2 http://git-scm.com/book/zh/v2，同时欢迎来审校中文版： https://github.com/progit/progit2-zh/issues/160

git reset --soft HEAD~1

链接发错了，链接和内容之间还必须隔一个半角空格。
ProGit v2 http://git-scm.com/book/zh/v2

git reset HEAD~1 应该等同 git reset --soft HEAD~1

--mixed 回到 commit 和 add 之前的状态
--soft 回到 commit 之前的状态
--hard 回到 commit 和 add 之前的状态并且丢掉你的改动

@morethansean
@networm 对不起我没看清LZ问题…… TAT
--hard会删掉修改的，LZ你千万别听我的啊！！！！
6楼正解 git reset --soft HEAD~1

@lijinma 不对 默认参数是 --mixed

@limuxy 为什么无视 4L

再说 6L 的也不对

@limuxy 楼主还需要保留修改，--hard 不得哭了....

使用 git reset --mixed HEAD~1 才是正解。

给个思路，先stash，再reset，再stash pop

补张图，关于--mixed, --soft, --hard

@YoungShook
@123123

哈哈，我查了，也试验了，--mixed 和 --soft 有一点点差别，不过不大，都可以。

--soft
Does not touch the index file or the working tree at all (but resets the head to <commit>, just like all modes do). This leaves all your changed files "Changes to be committed", as git status would put it.

--mixed
Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action.

If -N is specified, removed paths are marked as intent-to-add (see git-add(1)).



@chuan2015 如果直接使用 reset --mixed 或 --soft 话，不会丢失现在的修改，所以没必要 stash.

如果你的dev0还没提交的话最简单的方法是先修改好改成你要的样子
然后 git commit --amend 这个命令会直接修改你上一次的commit，加上你现在修改的东西，所以不需要stash 也不需要reset

hard reset 并不会把 commit 删掉，只是将其从 history 里删掉。

@1ang 哈哈，有道理，如果是刚好是上一次修改，amend 就可以，如果是上上次等修改，就需要 reset

感谢楼主的问题楼上诸位的回答，终于把这一块弄明白了

不是应该不管它，这次提交修改好就 OK 了

lz把时间顺序明确一下吧，总觉得0是最早的，但看语义似乎0是最近的？

reset应该只是把HEAD往古代方向挪了一下
但所有commit都是存在repo里的，还可以checkout出被reset掉的那个。但只有 有名字（HEAD、branch、tag、或者与他们有历史关系等） 的commits才会通过clone、push、pull传输到其他repo

如果只是撤销到add动作之前，还是用soft吧

HEAD~1 中的 ~1 指什么？

@CodingMonkey HEAD的上一个commit

这种情况不是改好之后 git commit --amend 不就行了

也可以先再提交一次，然后interactive rebase把两个提交合并。
当然amend最方便。
reset也可以只不过意义不大。

想要保险，先commit 后 ammend/rebase是最保险的，因为有reflog保底绝对一行也不会丢

https://www.atlassian.com/git/tutorials/resetting-checking-out-and-reverting/commit-level-operations
https://www.atlassian.com/git/tutorials/rewriting-history/git-commit--amend

被这个教程领进门的，Git 要用的淡定就得先把内部结构看完，然后还要把每个命令与那几个区域的变化关系理清楚。

一般不建议使用reset，这玩意会丢弃历史。

如果只是个别文件和个别行出问题，git checkout commit_id /path/to/file 把该版本中该文件弄出来，进行修改调整后，再add, commit。

如果对log有洁癖，等这部分工作结束后，使用rebase对提交历史进行集体处理，会好看很多。