索引是否有更新? [英] Is there a reflog for the index?

问题描述

我手头没有特定的问题，但是在过去的某些情况下，我不小心弄坏了索引，希望我可以返回给定文件的先前状态，该状态在某些情况下已被索引点.

I do not have a specific problem at hand, but I have encountered in the past some cases where I accidentally blew up my index, and wished I could go back the the previous state of a given file, which was indexed at some point.

一些例子是:

$ git add <file>
# find out that I already had an indexed version of <file>,
# and that for some reason I shouldn't have added the extra modifications

$ git stash pop
# find out afterwards that I have a mix of "the index I had"
# and "the index in the stash"

$ git stash
# with an active index, which is now mixed with the state of the working tree

$ git reset <typo>
# accidentally resetting the wrong file, or the whole directory

一个人可以诉诸于git fsck --full --unreachable --no-reflog(如建议

One could resort to digging through git fsck --full --unreachable --no-reflog (as suggested here), I was wondering if there was a more convenient way to do this.

问题:

索引是否有某种引用?

推荐答案

引用日志包含引用条目...而不是索引.

The reflog contains entries for refs...not the index.

但是，也许对工作流程进行调整是这里的答案...(这是给我的.)

But, perhaps a workflow tweak is the answer here...(it was for me).

如果要花5到10分钟以上的时间进行操作，请 按需提交 (并在推送之前进行清理).否则，按阶段进行.

If working on something that will take more than 5-10 minutes, commit-as-you-go (and cleanup prior to pushing). Otherwise, stage-as-you-go.

index很棒...我整天都用它！但是，只有在我知道在一两分钟之内提交(基本上是原子工作流操作)后，我才真正使用它.这是因为我害怕自己会做一些愚蠢的事情，使我的索引崩溃.

The index is great...I use it all day long! But I only really use it if I know that I will be commiting within just a minute or two (basically an atomic workflow operation). This is because I am scared that I will do something stupid and blow away my index.

我在工作时，每次达到一个里程碑时，我都会进行一次私人提交，通常只有在我有机会先进行一些清理之前，才会提交该私人提交.在处理该特定问题时，我会不断做出承诺，通常会进行修正.

While I am working, every time I reach a little milestone I make a private commit that usually will not be pushed until I've had a chance to do some cleanup first. I keep on commiting as I work on that specific problem, usually amending.

然后，一旦我实际上已经达到了要创建一个公共提交的稳定点，我就会压缩(如果需要)我所有的小wip提交，并给出一个不错的提交信息并推送.

Then, once I've actually reached a stable point where I want to create a public commit I squash (if needed) all my little wip commits together, give a nice commit message and push.

这提供了巨大的优势，如果需要的话，可以在我的reflog中创建少量面包屑.

This gives the huge advantage of creating little breadcrumbs in my reflog if needed.

这是我的工作流程:

# start work
git checkout -b featurea
# work
vim file.txt
# reach a little milestone
git commit -a -m "working on feature..."
# work some more
vim file.txt
# reach another little milestone
git commit -a --reuse-message=HEAD --amend
# work some more
vim file.txt
# another little milestone...
git commit -a --reuse-message=HEAD --amend
# finishing touches...
vim file.txt
# ok, done now, put everything back in working dir so I can review
git reset HEAD~
# decide what goes in this commit
# perhaps use `git add -p`
git add file.txt
# give a nice commit message (use editor)
git commit
# now merge to master and push with confidence!

这看起来像是很多次键入，但是如果您擅长在shell上飞行(利用set -o emacs或set -o vi是一个好方法)，那么这种方法几乎是即时的.

This may seem like a lot of typing, but if you get good at flying on the shell (taking advantage of set -o emacs or set -o vi is a good way) then this approach becomes almost instant.

如果我真正从事的工作是非常快速的修复，那么我通常只会使用现阶段的方法，但是任何比我更长的时间，我都需要在随行添加reflog的安全性.

If what I'm working on truly is a very quick fix I will typically just use the stage-as-you-go approach, but anything longer than that I need the safety of populating my reflog as I go.

这篇关于索引是否有更新?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！