在意外结账后取回更改？ [英] Get back the changes after accidental checkout?

问题描述

  [〜/ rails_apps / jekyll_apps / nepalonrails（design）⚡]➔]➔ gst 
＃分支设计
＃已更改但未更新：
＃（使用git add / rm< file> ...更新将提交的内容）
 ＃（使用git checkout  - < file> ...放弃工作目录中的更改）
＃
＃modified：_layouts / default.html 
＃deleted：_site / blog /2010/04/07/welcome-to-niraj-blog/index.html 
＃已删除：_site / blog / 2010/04/08 / the-code-syntax-highlight / index.html 
 ＃deleted：_site / blog / 2010/05/01 / showing-demo-to-kalyan / index.html 
＃deleted：_site / config.ru 
＃deleted：_site / index.html 
＃deleted：_site / static / css / style.css 
＃deleted：_site / static / css / syntax.css 
＃modified：static / css / style.css 
＃
没有更改添加到提交（使用git add和/或git commit -a）
  

接受，我做了 git checkout -

$ b

  [〜/ rails_apps / jekyll_apps / nepalonrails（设计）]➔git co -f 
 [〜/ rails_apps / jekyll_apps / nepalonrails（设计）]➔gst 
＃分支设计
不需要提交（工作目录清理）
 [〜/ rails_apps / jekyll_apps / nepalonrails（设计）]➔
  

我可以得到返回变更回来？

解决方案

我不认为你可以恢复这些私人数据（私人在索引中，也没有承诺，所以未知的git），除非你有其他的备份过程适用于你当前的工作目录。

即使这不是建议 Git Aliases页面 ，我会为某些人辩护（如code> alias rm / bin / rm -i 用法）：

  [别名] 
 co =！sh -c'git stash; git存储适用; git checkout$ *'
  

，用' git stash; git stash apply '是 Brian Campbell 在他的答案。

<这个问题让我想起了关于 ycombinator （摘录）的这种行为的辩论：

---

我用git丢失了大量数据。

大部分与删除数据时无需确认的无害声音命令有关。
例如， git checkout filename 相当于 svn revert filename 。

当然 git checkout branchname 一些完全不同的东西。

如果一个分支和一个文件共享同一个名字，git将默认切换分支，但这并不能阻止bash自动完成f rom破坏了一天。

这是一个疯狂的想法：如果你有一个无害的动作和一个危险的动作，不要用同样的命令标记它们。 b $ b

---

恼人的也许，但这是用户错误，不是设计错误。有了git，如果我想无损丢弃我的工作副本，我可以 git stash 。

根据您的逻辑，rm有缺陷因为当您传递 -f 而不是 -i 时，它不会要求确认。那么，是的。

---

rm somename 相当于 apt-get update ， rm othername rm -fr othername 。

然而，它不可能是 get checkout foo code>完成两个完全不同的事情之一，具体取决于当前目录中是否存在名为foo的文件








---

下面是另一个疯狂的想法：不要在一个运行' git checkout ... '的肮脏的工作树。问题解决了。

另一个：不要重复使用文件名作为分支名称。

说实话：我有同样的问题，不小心调用' rm '毁了我的一天，但是当我在嘟curs诅咒时，它在我的懒惰/愚蠢，而不是在bash完成或' rm '

The following was the status of my repo.

[~/rails_apps/jekyll_apps/nepalonrails (design)⚡] ➔ gst
# On branch design
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   _layouts/default.html
#   deleted:    _site/blog/2010/04/07/welcome-to-niraj-blog/index.html
#   deleted:    _site/blog/2010/04/08/the-code-syntax-highlight/index.html
#   deleted:    _site/blog/2010/05/01/showing-demo-to-kalyan/index.html
#   deleted:    _site/config.ru
#   deleted:    _site/index.html
#   deleted:    _site/static/css/style.css
#   deleted:    _site/static/css/syntax.css
#   modified:   static/css/style.css
#
no changes added to commit (use "git add" and/or "git commit -a")

Accedently, I did git checkout -f and now the changes are gone which I wasnt supposed to do.

[~/rails_apps/jekyll_apps/nepalonrails (design)⚡] ➔ git co -f
[~/rails_apps/jekyll_apps/nepalonrails (design)] ➔ gst
# On branch design
nothing to commit (working directory clean)
[~/rails_apps/jekyll_apps/nepalonrails (design)] ➔ 

Can I get back the changes back?

解决方案

I don't think you can recover those private data ("private" as in "not added in the index, nor committed", so unknown to git), unless you have other backup process in place for your current working directory.

Even if this is not proposed in the Git Aliases page, I would argue for some kind alias for checkout (like there is the alias rm /bin/rm -i usage):

[alias]
co = !sh -c 'git stash; git stash apply; git checkout "$*"'

, with the 'git stash; git stash apply' being the "checkpoint technique" used by Brian Campbell in his answer.

This issue reminds me of a debate on this behavior on ycombinator (extracts):

---

I've lost plenty of data with git.
Most of it has to do with innocuous-sounding commands that don't ask for confirmation when deleting data.
For example, git checkout filename is equivalent to svn revert filename.
Of course git checkout branchname does something completely different.
If a branch and a file share the same name, git will default to switching branches, but that doesn't stop bash autocomplete from ruining the day.

Here's a crazy idea: If you have an innocuous action and a dangerous action, do not label them with the same command.

---

Annoying, maybe, but this is user error, not design error. With git, if I want to losslessly discard my working copy, I can just "git stash".
By your logic, "rm" is flawed because it doesn't ask for confirmation when you pass -f instead of -i. Well, yeah. Sorry.

---

Your analogy would be more accurate if rm somename was the equivalent of apt-get update, and rm othername was rm -fr othername.
Still, it can't be right that "get checkout foo" does one of two COMPLETELY different things depending on whether or not there is a file called foo in the current directory

---

Here's another crazy idea: don't run 'git checkout ...' on a dirty work tree. Problem solved.
Another one: don't reuse filenames as branch-names.
To be honest: I have the same problem with careless invocations of 'rm' ruining my day but when I'm muttering curses it is at my lazyness/stupidity and not at bash completions or the behavior of 'rm'

这篇关于在意外结账后取回更改？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！