在使用 Git 的过程中,有时会不小心丢失 commit 信息.这一般出现在以下情况下:强制删除了一个分支而后又想重新使用这个分支,hard-reset 了一个分支从而丢弃了分支的部分 commit.如果这真的发生了,有什么办法把丢失的 commit 找回来呢? 通常最快捷的办法是使用 git reflog 工具.当你 (在一个仓库下) 工作时,Git 会在你每次修改了 HEAD 时悄悄地将改动记录下来.当你提交或修改分支时,reflog 就会更新.git update-ref 命令也可以更新

最近...似乎一直在踩坑... 也不是什么故障,只是把一个分支的功能弄没了,之后在reflog里找到又恢复了. 产生原因是有同事错误地把分支B merge到了分支A并push. 我直接在分支A上reset到了merge前的一个节点(但这个节点其实是B分支的). 这导致分支A的头跑到了B分支上,A本来那个分支没有引用就丢了. 先说下解决方法,git reflog找到那个reset,或者直接用git fsck --no-reflogs --unreachable找到那个commit之后直接再rese

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

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

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

git reset --hard <commit>: 1.替换引用的指向.引用指向新的提交ID; 2.替换暂存区.替换后,暂存区的内容和引用指向的文件夹树一致; 3.替换工作区.替换后,工作区的内容变得和暂存区一致,也和HEAD所指向的文件夹树内容同样. git reset --soft <commit>: 1.替换引用的指向.引用指向新的提交ID. 即仅仅更改引用的指向,不该编暂存区和工作区. git reset --mixed <commit>或git reset

很多时候,git新手容易误操作,比如,在levelIISZ-1.4.dev分支下,运行了git pull idc cpp-1.0的结果,这样做麻烦很大,经常导致maven项目格式不正确,这个时候,可以用git reset --hard 去撤销这次修改但是这样做也有问题,可能之前本地的,没有提交的修改,都消失了.可以尝试git revert命令 reset是指将当前head的内容重置,不会留任何痕迹. git reset --hard HEAD~3 会将最新的3次提交全部重置,就像没有提交过一样.

一.命令 首先,让我们来解释几个定义.   HEAD(头)     指向当前branch最顶端的一个commit,该分支上一次commit后的节点   Index(索引)     The index, 也可以被认为是staging area(暂存区), 是一堆将在下一次commit中提交的文件,提交之后它就是 HEAD的父节点. (译注:git add添加的文件)   Working Copy(工作副本)     当前工作目录下的文件,(译注:一般指,有修改,没有git add,没有git co

重置命令(git reset)是Git 最常用的命令之一,也是最危险最容易误用的命令.来看看git reset命令用法. ----------------------------------------------------------------------------------------------------------- 用法一:git reset [-q]  [<commit>] [--] <paths>..... 用法二:git reset [--soft | -

关于git reset --hard xxxxxxx命令之Git版本回退 今晚代码写着写着就头脑有点发懵,手指也不听使唤了竟然让我敲出了 git reset --hard 命令,然后的然后就是之前所有增改的东西都不见了!!! 慌忙之下赶紧找啊找,还是找不到了,此刻的心情...是多么地复杂!!!怎么办么?赶紧网上找找看有谁曾和我一样倒霉过,好吧第一个就是了,讲解的很详细全面,我真幸运!简述一下就是: [1]如果你所修改的东西都没有 git commit,甚至也都没有 git add . 或者 gi

一,git clone 1,git clone某一个分支 git clone -b <branch> <remote_repo> 2,.git 文件太大 :clone的时候,可以指定深度,如下,为1即表示只克隆最近一次commit. 二,撒销一个合并 如果你觉得你合并后的状态是一团乱麻,想把当前的修改都放弃,你可以用下面的命令回到合并之前的状态: $ git reset --hard HEAD 或者你已经把合并后的代码提交,但还是想把它们撒销: $ git reset --hard

参考: 找回Git中丢失的Commit Git误操作 git reset强制回滚 恢复commit方法 使用Git时,常有误操作,在Commit之后又执行了git reset --hard HEAD强制回滚本地记录以及文件到服务器版本,导致本地做的修改全部恢复到Git当前分支的服务器版本,同时Commmit记录也消失了. 此时解决方法是通过git reflog来查看先前记录并恢复: git reflog会记录所有HEAD的历史,也就是说当你做 reset,checkout等操作的时候,这些操作会

  git reset --hard和git revert命令   git误操作时可以用git reset –hard 去撤销这次修改, 但是这样做也有问题,可能在之前本地有没有提交的修改也都消失了,这种情况下,可以尝试git revert命令. 一 git reset的使用 reset是指将当前head的内容重置,不会留任何痕迹. Sets the current head to the specified commit and optionally resets the index and

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

[转]git reset 之 soft mixed hard选项的区别 (2014-09-09 16:54:06) 转载▼ 标签: git 分类: Linux 译注:为了避免丢失本地的修改以及original HEAD,建议在进行reset操作之前,在本地创建一个新的branch,在新的branch上面进行reset,以保证master分支永远处于original HEAD 以下为转发的正文 The reset command. Confusing. Misunderstood. Misused

Git command之回退篇 欲练回退 必先了解:HEAD.index.WorkingCopy HEAD: 当前所在的分支版本顶端的别名,也就是最新的一次commit. git commit 之后与HEAD一致 index: staging area,git add 之后放入该区域 WorkingCopy: 当前修改等操作所在区域,没有 git add 和 git commit 操作 git reset HEAD --file (单个文件) 可与git checkout --file配合 回退

Git版本回滚之 git revert 与 git reset 在使用 git 的时候,如果错误push之后,经常会回滚版本. git的回滚有两种方式: revert命令:这种方式,是用一种反向的 push 来重新提交一次.git中可以看到操作记录. reset命令:这个命令,是一种重置.即错误提交了,我要删除这个提交记录.也可以实现回滚. 两个命令的对比: revert 和 reset 看上去达到的效果是一样的,但其实是完全不同的过程. 如果已经 push 到线上代码库, reset 删除指定