如何“git diff”工作树到储藏室?
如何查看取消存储将对当前工作树造成的更改?我想知道在应用之前会进行哪些更改!
How can I see the changes un-stashing will make to the current working tree? I would like to know what changes will be made before applying them!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(15)
查看最新的存储:
查看任意存储:
来自
git stash
联机帮助页:See the most recent stash:
See an arbitrary stash:
From the
git stash
manpages:要查看最新的存储:
要查看任意存储:
另外,我使用 git diff 将存储与任何分支进行比较。
您可以使用:
查看与分支主服务器相比的所有更改。
或者您可以使用:
轻松查找仅更改的文件名。
To see the most recent stash:
To see an arbitrary stash:
Also, I use git diff to compare the stash with any branch.
You can use:
To see all changes compared to branch master.
Or You can use:
To easy find only changed file names.
如果您存储的更改所基于的分支同时发生了更改,则此命令可能很有用:
这会将存储与其所基于的提交进行比较。
If the branch that your stashed changes are based on has changed in the meantime, this command may be useful:
This compares the stash against the commit it is based on.
根据您想要比较存储的内容(本地工作树/父提交/头提交),实际上有几个可用的命令,其中有很好的旧
git diff
和更具体的git stash show
:git diff stash@{0}
git stash show -l
git stash show -p
git diff stash@{0} HEAD
/
While
git stash show 乍一看看起来更加用户友好,git diff 实际上更强大,因为它允许指定文件名以进行更集中的差异。我亲自在我的 zsh git 插件。
Depending on what you want to compare the stash with (local working tree / parent commit / head commit), there are actually several commands available, amongst which the good old
git diff
, and the more specificgit stash show
:git diff stash@{0}
git stash show -l
git diff stash@{0}^ stash@{0}
git stash show -p
git diff stash@{0} HEAD
/
While
git stash show
looks more user friendly on first sight,git diff
is actually more powerful in that it allows specifying filenames for a more focused diff. I've personally set up aliases for all of these commands in my zsh git plugin.如果您的工作树是脏的,您可以通过首先提交脏工作树,然后将其与存储进行比较,将其与存储进行比较。之后,您可以使用脏工作树撤消提交(因为您可能不希望在提交日志中保留该脏提交)。
您还可以使用以下方法来相互比较两个存储(在这种情况下,您只需首先弹出其中一个存储)。
提交你的脏工作树:
<前><代码>git add .
git commit -m“脏提交”
将存储与该提交进行比较:
然后,您可以恢复提交,并将其放回工作目录中:
现在您已经将脏工作树与存储区进行了比较,并返回到最初的位置。
If your working tree is dirty, you can compare it to a stash by first committing the dirty working tree, and then comparing it to the stash. Afterwards, you may undo the commit with the dirty working tree (since you might not want to have that dirty commit in your commit log).
You can also use the following approach to compare two stashes with each other (in which case you just pop one of the stashes at first).
Commit your dirty working tree:
Diff the stash with that commit:
Then, afterwards, you may revert the commit, and put it back in the working dir:
Now you've diffed the dirty working tree with your stash, and are back to where you were initially.
@Magne 的答案是迄今为止唯一一个(很晚)回答该问题最灵活/有用的解释的答案,但是它比必要的要复杂一些。无需提交和重置,只需隐藏您的工作副本,进行比较,然后取消隐藏。
通过暂时使工作文件夹更改成为存储堆栈的顶部 (stash@{0}),将原始顶部向下移动 (stash@{1}),可以显示存储堆栈顶部和工作文件夹之间的差异)然后在“新设置”位置使用原始顶部进行比较,以便您看到将其应用到当前工作顶部所产生的变化。
“但是如果我当前没有任何工作怎么办?”那么你就处于正常的无聊情况。只需使用 @Amber 的答案
或 @czerasz 的答案
,或者承认存储和取消存储是快速且简单的,只需取消存储更改并检查它们即可。如果您现在不需要它们,请将它们扔掉(当前索引/工作文件夹发生变化)。完整来说就是
@Magne's answer is the only one to (very late) date that answers the most flexible/useful interpretation of the question, but its a fair bit more complicated than necessary. Rather than committing and resetting, just stash your working copy, compare, then unstash.
That shows you the differences between the top of the stash stack and your working folder by temporarily making your working folder changes become the top of the stash stack (stash@{0}), moving the original top down one (stash@{1}) then comparing using the original top in the 'new set' position so you see the changes that would result from applying it on top of your current work.
"But what if I don't have any current work?" Then you are in the normal boring case. Just use @Amber's answer
or @czerasz's answer
or admit that stashing and unstashing is fast and easy anyway, just unstash the changes and inspect them. If you don't want them at the moment throw them (the current index/working folder changes) away. In full that's
以防万一,要比较工作树和存储中的文件,请使用以下命令
Just in case, to compare a file in the working tree and in the stash, use the below command
这对我的 git 版本 1.8.5.2 有效:
This works for me on git version 1.8.5.2:
如果你有比较工具(比如超越比较)
If you have tools for diff (like beyond compare)
我相信
git diff..stash@{0}
是比较本地工作树和最新存储之间的更改的最直观方法。根据需要将stash@{0}
替换为适用的存储编号。请注意
git diff stash@{0}
可能会产生误导性结果。如果您的存储和当前分支的两个历史记录出现了分歧,则差异看起来就像您在存储中添加了所有新内容并删除了当前分支特有的所有内容。答案基于 git 书
另外,请注意双点
..
和三点...
指定不同的提交比较,我指的是这个答案的双点。 有关详细信息,请参阅 git 书籍I believe
git diff <current-branchname>..stash@{0}
is the most intuitive way to compare the changes between the local working tree and the most recent stash. Replacestash@{0}
with the applicable stash number as needed.Beware that
git diff stash@{0}
may produce misleading results. If the two histories of your stash and current branch have diverged, the diff will look like you’re adding all the new stuff in your stash and removing everything unique to the current branch.answer based on the git book
Also, note that double dot
..
and triple dot...
specify different commit comparisons, and I am referring to the double dot for this answer. See the git book for details我发现这里的答案都没有给出我的用例所需的内容:
我发现工作树和存储之间的最好差异是:
或者简单地说:
但这显示了差异与我预期的方式相反:添加的行(通常为绿色)显示为已删除(通常为红色),反之亦然。
反转 diff 得到了我需要的东西:
此时,在存储之后运行此命令会得到与在存储之前运行 git diff 相同的结果。
I found that none of the answers here gave me quite what I needed for my use case:
The best I found for a diff between the working tree and the stash was:
or simply:
But this showed the diff the wrong way round for how I expected it: Lines added (usually in green) were shown as removed (usually red), and vice versa.
Reversing the diff got me what I needed:
At this point you get identical results running this command after stashing as you would running
git diff
before the stash.在不移动任何内容的情况下执行此操作的一种方法是利用
patch
可以读取 git diff 的事实(基本上是统一的差异)这将向您展示补丁通常会执行的操作的逐步预览。这样做的额外好处是,补丁也不会阻止自己将补丁写入工作树,如果由于某种原因你真的需要 git 停止修改前的提交,请继续并删除 --dry-运行并按照详细说明进行操作。
One way to do this without moving anything is to take advantage of the fact that
patch
can read git diff's (unified diffs basically)This will show you a step-by-step preview of what patch would ordinarily do. The added benefit to this is that patch won't prevent itself from writing the patch to the working tree either, if for some reason you just really need git to shut up about commiting-before-modifying, go ahead and remove --dry-run and follow the verbose instructions.
她是存储列表
所以获取存储编号并执行以下操作:
您可以这样做:
但是如果您想要一个差异(这与显示存储不同,这就是我写这个答案的原因。
Diff
考虑分支中的当前代码,show
仅显示您将应用的内容)您可以使用:
或
另一个有趣的事情是:
这会应用存储而不将其从列表中删除,你可以
git checkout。
删除这些更改,或者如果您愿意git stash drop stash@{10}
从列表中删除存储。从这里开始,我从不建议使用 git stash pop 并使用 git stash apply 和 git stash drop 的组合。错误的分支...有时很难恢复你的代码。
She the list of stash
So get the stash number and do:
You can do:
But if you want a diff (this is different to show the stash, that's why I write this answer.
Diff
consider the current code in your branch andshow
just show what you will apply)You can use:
or
Another interesting thing to do is:
This applies the stash without removing it from the list, you can
git checkout .
to remove those change or if you are happygit stash drop stash@{10}
to remove a stash from the list.From here I never recommend to use
git stash pop
and use a combination ofgit stash apply
andgit stash drop
If you apply a stash in the wrong branch... well sometimes is difficult to recover your code.结合我在这个帖子和这个帖子中学到的知识,当我想要看到“存储中的内容”,我首先运行:
这将显示修改了哪些文件。然后,为了在 difftool 中获得良好的视觉差异,我这样做:
这将立即显示给定存储与其父存储的所有差异。
您可以在
~/.gitconfig
中配置 diff 工具,例如使用 Meld:Combining what I learned in this thread and in this one, when I want to see "what is inside the stash", I first run:
That will show what files were modified. Then, to get a nice visual diff in a difftool, I do:
This will display all the differences at once of the given stash against its parent.
You can configure the diff tool in
~/.gitconfig
, e.g. with Meld:FWIW
这对于所有其他答案来说可能有点多余,并且与已接受的答案非常相似;但也许它会对某人有所帮助。
git stash show --help
将为您提供您应该需要的一切;包括隐藏的演出信息。FWIW
This may be a bit redundant to all the other answers and is very similar to the accepted answer which is spot on; but maybe it will help someone out.
git stash show --help
will give you all you should need; including stash show info.