[英]use git stash version in case of merge conflict
I just did我已经做了
git stash
git pull
git stash apply
and got the message并收到消息
Auto-merging my_notebook.ipynb
CONFLICT (content): Merge conflict in my_notebook.ipynb
It's a binary file, so I wouldn't know how to manually resolving the conflict like I normally do for source code merge conflicts.这是一个二进制文件,所以我不知道如何像通常处理源代码合并冲突那样手动解决冲突。
How can I just replace the file in my working directory with the file that I stashed?我怎样才能用我隐藏的文件替换我工作目录中的文件? Overwrite the version that was pulled?
覆盖拉取的版本?
This is relatively straightforward.这是相对简单的。 The stash itself consists of two (or sometimes three, but in this case, two) commits, one of which you can refer to with the name
stash
and one that requires the name stash^2
.存储本身由两个(或有时三个,但在本例中为两个)提交组成,您可以使用名称
stash
引用其中一个,另一个需要名称stash^2
。 The one under stash
is the one that corresponds to your working directory at the time you ran git stash
, so that's the one you want. stash
下的那个是您运行git stash
时对应于您的工作目录的那个,所以这就是您想要的那个。
Hence any of these will work on a Unix/Linux system:因此,这些中的任何一个都可以在 Unix/Linux 系统上运行:
git restore --worktree --source=stash my_notebook.ipynb
git show stash:my_notebook.ipynb > my_notebook.ipynb
git checkout stash -- my_notebook.ipynb
The first is generally the one to use because it also works on other less friendly systems, such as Windows. Note that it writes only to your working tree copy.第一个通常是要使用的,因为它也适用于其他不太友好的系统,例如 Windows。请注意,它只写入您的工作树副本。 The second also writes only to the working tree copy (using I/O redirection), but the third writes to both Git's index (aka "the staging area") and your working tree copy.
第二个也只写入工作树副本(使用 I/O 重定向),但第三个写入 Git 的索引(又名“暂存区”)和你的工作树副本。 You might want this so that you need not run
git add
on the file afterward;你可能想要这个,这样你就不需要在之后运行
git add
文件; in that case, you can get this effect by modifying your git restore
command to use git restore -SW --source stash
for instance.在这种情况下,您可以通过修改
git restore
命令以使用git restore -SW --source stash
来获得此效果。 1 1个
(Because git stash apply
ran an internal merge with an "ours" and "theirs" commit, it's possible to use --ours
or --theirs
to extract the HEAD
and working-tree versions, but, given how they get swapped around by various operations, 2 even I can't keep track of which one is which myself and hence I don't recommend git checkout --ours
or git restore --theirs
or whatever here. Just name stash
directly so that you know which commit you mean.) (因为
git stash apply
运行了与“我们的”和“他们的”提交的内部合并,所以可以使用--ours
或--theirs
来提取HEAD
和工作树版本,但是,考虑到它们是如何交换的各种操作, 2甚至我自己也无法跟踪哪个是哪个,因此我不推荐git checkout --ours
或git restore --theirs
或此处的其他任何内容。直接命名stash
以便您知道哪个提交意思。)
1 The -S
or --staged
option means write to staging and the -W
or --worktree
option means write to the working tree . 1
-S
或--staged
选项表示写入暂存, -W
或--worktree
选项表示写入工作树。 The --source
option can take =stash
or stash
as a separate word. --source
选项可以将=stash
或stash
作为一个单独的词。 The idea here was to show all the different ways to invoke this.这里的想法是展示调用它的所有不同方式。
2 Eg, during git merge
, --ours
makes sense, but during git rebase
, --ours
often doesn't and --theirs
means "my original commit", which seems like it should be called "ours". 2例如,在
git merge
期间, --ours
有意义,但在git rebase
期间, --ours
通常没有意义,-- --theirs
表示“我的原始提交”,这似乎应该称为“我们的”。 There are always technical reasons for whatever the outcome ends up being, and one can always work it out from first principles, but for something one does rarely, it seems silly to bother.无论结果最终是什么,总是有技术原因,人们总是可以从第一原则中得出结论,但对于很少有人做的事情,麻烦似乎很愚蠢。 Naming the commit directly is easier.
直接命名提交更容易。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.