在开发过程中,git的版本管理越来越普及.在版本管理中,最常用和最重要的是重置提交的版本,恢复后悔做了的事.大家都知道用reset命令.但是有几种形态需要整理共享一下,也方便我自己查阅. 一.首先解析以下这三个相关的状态和概念, 1.HEAD:可以描述为当前分支最后一个提交.即本地的信息中的当前版本. 2.Index:在工作副本修改之后执行过git add操作的版本文件,可以commit了的. 3.Working Copy:工作副本是你正在修改,但是没有执行任何git操作的文件. 总的来说, 代

http://blog.csdn.net/hudashi/article/details/7664464 http://guibin.iteye.com/blog/1014369 http://hi.baidu.com/tiger_tnt/blog/item/a0464ffa6a8115d9b58f314d.html http://web.mit.edu/~mkgray/project/silk/root/afs/sipb/project/git/git-doc/git-reset.html 一

http://alpha-blog.wanglianghome.org/2010/07/30/git-partial-rollback/ reset(版本撤回) 格式 git reset [-q] [<commit>] [--] <paths>...git reset (--patch | -p) [<commit>] [--] [<paths>...]git reset (--soft | --mixed | --hard | --merge | --ke

下面方法只针对当你本地代码做了 git add 或则 git commit 后又手贱的重置本地代码到上一个版本,导致本地代码丢失的情况. 如果你没有 git add 命令,而直接 git reset --hard 了,抱歉,代码估计找不回来了. 一,第一种情况 git commit 后重置代码 1,在所在代码文件路径下执行 git reflog 这样就能看到所有的 commit 后的记录. e294e2a HEAD@{5}: commit: 处理冲突 2d6c4d7 HEAD@{6}: comm

reset三种模式区别和使用场景 区别: --hard:重置位置的同时,直接将 working Tree工作目录. index 暂存区及 repository 都重置成目标Reset节点的內容,所以效果看起来等同于清空暂存区和工作区. --soft:重置位置的同时,保留working Tree工作目录和index暂存区的内容,只让repository中的内容和 reset 目标节点保持一致,因此原节点和reset节点之间的[差异变更集]会放入index暂存区中(Staged files).所以效

背景 当我们修改了代码准备提交时,本地的改动可能包含了不能提交的调试语句,还可能需要拆分成多个细粒度的 pactch. 本文将介绍如何使用 git add -p 来交互式选择代码片段,辅助整理出所需的 patch. 官方介绍 先贴个帮助信息供参考 英文版本: -p, --patch Interactively choose hunks of patch between the index and the work tree and add them to the index. This give

一,git reset的功能: 该命令修改HEAD的位置,即将HEAD指向的位置改变为之前存在的某个版本, 说明: 修改后,push到远程仓库时需要使用"git push -f"提交更改 原因:因为我们本地库HEAD指向的版本比远程库的要旧 说明:架构森林是一个专注架构的博客,地址:https://www.cnblogs.com/architectforest 对应的源码可以访问这里获取: https://github.com/liuhongdi/ 说明:作者:刘宏缔 邮箱: 3711

git reset 操作 git reset git reset HEAD 文件名 移除不必要的添加到暂存区的文件 git reset HEAD^ 或者 commitid 去掉上一次的提交 git reset --soft HEAD^ 修改上次提交的信息,即commit -m "修改这里的内容" git reset --soft 只是将HEAD引用指向指定的提交,工作区跟暂存区的内容不会改变 git reset --mixed (默认选项)将HEAD指向指定的提交,暂存区的内容随之改变

git revert 是撤销某次操作,此次操作之前的commit都会被保留 git reset 是撤销某次提交,但是此次之后的修改都会被退回到暂存区 具体一个例子,假设有三个commit, git st: commit3: add test3.c commit2: add test2.c commit1: add test1.c 当执行git revert HEAD~1时, commit2被撤销了 git log可以看到: commit1:add test1.c commit3:add test

git reset.git checkout和git revert是你的Git工具箱中最有用的一些命令.它们都用来撤销代码仓库中的某些更改,而前两个命令不仅可以作用于提交,还可以作用于特定文件. 因为它们非常相似,所以我们经常会搞混,不知道什么场景下该用哪个命令.在这篇文章中,我们会比较git reset.git checkout和git revert最常见的用法.希望你在看完后能游刃有余地使用这些命令来管理你的仓库. Git仓库有三个主要组成——工作目录,缓存区和提交历史.这张图有助于理解每个

一不小心在eclipse的git库中执行了Reset Soft(HEAD ONLY)操作,不料界面中竟然没有找到撤销方法(于是心中五味俱全,经过一番折腾,无果还是回归Git本身),最终通过命令行,很快搞定撤销了,其实有2种方法可以还原. 方法一: 1.先通过git reflog找到上一次的历史提交记录id,git如果没有特意设置,是会保存记录一段时间的(a few days or a month) 2.git reset --hard [id] 方法二: git reset --hard HEA

svn/git的diff.patch 前几天,正当我突突的写代码,企业微信嘀嘀一声响”在不,过来帮我看个bug”.本人一向助人为乐,高兴的冲了过去,然后就开始了一段长达1分钟的问题描述.很明显,此同学只知道结果不对,并没有找出程序的根本问题. 好吧,心凉了一半,果然是找我来干体力活的.坐定,抬手开始调试代码... 调试开始,打开编辑器,什么,竟然用的大型IDE,好吧,忍了,卡死了.刚写好一句代码,准备按ctrl+B运行,没反应,再按,依然没反应,好吧,看来这兄弟啥也没配置.刚想打开终端,想想算了

转帖:http://hi.baidu.com/configuration/item/97fddeea252818d0eb34c964 有时候使用Git工作得小心翼翼,特别是涉及到一些高级操作,例如 reset, rebase 和 merge.甚至一些很小的操作,例如删除一个分支, 我都担心数据丢失. 不 久之前,我在做一些大动作(rebasing)之前,我总是备份整个版本库,以防万一.直到最近我才发现git的历史记录是不可修改的, 也就是说你不能更改任何已经发生的事情.你做的任何操作都只是在原来

git reset revert 回退回滚取消提交返回上一版本 总有一天你会遇到下面的问题. (1)改完代码匆忙提交,上线发现有问题,怎么办? 赶紧回滚. (2)改完代码测试也没有问题,但是上线发现你的修改影响了之前运行正常的代码报错,必须回滚. 这些开发中很常见的问题,所以git的取消提交,回退甚至返回上一版本都是特别重要的, 大致分为下面2种情况:  1.没有push 这种情况发生在你的本地代码仓库,可能你add ,delete,commit 以后发现代码有点问题,准备撤销本次commit,

在使用git的时候不免遇到commit的时候commit了错误的代码的时候,这时候就需要用到git的常用命令之一  reset了. reset顾名思义为重置.重置的是HEAD指针,可以使HEAD指针移动到任意commit上. 使用git log [--oneline] 命令查看之前所有的commit id.然后使用git reset命令使HEAD指针指向其中的一个id. git reset 有三个可选参数 --hard  --mixed  --soft 其中--hard参数表示不但重置HEAD指

git reset 如果说git revert是一个安全的撤销方式, 那么git reset就是一个非常危险的方法了. 当你使用git reset撤销的时候, 你没有可能在回到最初了-他是一个永久的不可撤销的undo. git reset时Git命令中唯一一个有可能丢失你工作的命令. git reset可以用来删除已经commit了的快照, 但是他更多的是用来撤销在stage区和工作目录下的修改. git reset应该只用来撤销本地的修改-不应该使用reset撤销和其他开发者一起共享的comm

有时候使用Git工作得小心翼翼,特别是涉及到一些高级操作,例如 reset, rebase 和 merge.甚至一些很小的操作,例如删除一个分支,我都担心数据丢失. 不 久之前,我在做一些大动作(rebasing)之前,我总是备份整个版本库,以防万一.直到最近我才发现git的历史记录是不可修改的,也就是说你不能更 改任何已经发生的事情.你做的任何操作都只是在原来的操作上修改.也就是说,即使你删除了一个分支,修改了一个提交,或者强制重置,你仍然可以回滚这些操 作. 让我们来看一些例子: $ git

git revert 撤销 某次操作,此次操作之前和之后的commit和history都会保留,并且把这次撤销 作为一次最新的提交    * git revert HEAD                  撤销前一次 commit    * git revert HEAD^               撤销前前一次 commit    * git revert commit (比如:fa042ce57ebbe5bb9c8db709f719cec2c58ee7ff)撤销指定的版本,撤销也会作为一

git的几种回滚 git revert 和 git reset的区别:强烈建议:对HEAD不熟的话最好不要用HEAD,直接用commitID吧,我遇到的问题:reset HEAD~1之后,可能是别人提交了 修改的,导致出现很多不是我做的修改记录需要提交.1.回滚版本,但是会在commit记录中新加一条记录revert的commit记录:git revert HEAD~1 执行 之后,会有提交信息, 提交后git log 2.回滚版本,保留本地的修改记录,可以重新直接commit用:git res

Git reset 1. 文件从暂存区回退到工作区 2. 版本回退 1.1 git reset HEAD filename :回退文件,将文件从暂存区回退到工作区 //也可以使用 git reset filename 1.2 git reset HEAD^ :回退版本,一个^表示一个版本,可以多个,另外也可以使用 git reset HEAD-n这种形式. 如果HEAD指针指向的是master分支,那么HEAD还可以换成master,如果知道特定的commit-id,那么还可以直接使用 git

GIT reset命令,似乎让人很迷惑,以至于误解,误用.但是事实上不应该如此难以理解,只要你理解到这个命令究竟在干什么. 首先我们来看几个术语 HEAD 这是当前分支版本顶端的别名,也就是在当前分支你最近的一个提交 Index index也被称为staging area,是指一整套即将被下一个提交的文件集合.他也是将成为HEAD的父亲的那个commit Working Copy working copy代表你正在工作的那个文件集 Flow 当你第一次checkout一个分支,HEAD就指向当前