使用git解决合并冲突后还原_远程uu文件

我在

并行分支中对本地文件做了几处更改。我使用
git stash
保存我的更改，并将其他更改保存到
master
中，而无需在线推送。因此，我必须解决一些关于文件的合并冲突，以减少文件的冗余。一步一步，这是我在git bash上的代码：

git stash
git pull origin master
git stash pop
git mergetool

我使用
meld
作为合并工具解决了关于一个文件
myFile.py
的冲突。我的问题是，在合并步骤中，我忘记了
remote
文件（
myFile\u remote\u 7572.py
）中的大部分代码。现在，我在笔记本电脑上找不到文件。我想还原它，以便在不重新启动合并步骤的情况下找到我的上一个代码。谢谢

在不重新启动合并步骤的情况下，无法还原代码（在此场景中）

但是，如果重新启动合并步骤，将通过以下步骤达到所需状态：

如果
myFile\u remote\u 7572.py
处于隐藏更改中

要返回主控台：
git签出主控台
要获取最新的更改：
git fetch上游；git合并上游/主节点
要更正我的新分支：
git签出新分支；git rebase主机
要应用正确的隐藏更改：
git stash apply
Git足够聪明，如果它不干净地应用，就不会丢失隐藏


如果
myFile\u remote\u 7572.py
在遥控器上

获取最新更改：
git fetch
从远程签出文件：
git Checkout origin/master--path/to/file/myFile\u remote\u 7572.py
fetch
将下载所有最近的更改，但不会将其放入当前签出的代码（工作区）

checkout
将使用下载的更改（
origin/master
）中的特定文件更新工作树。
虽然
git mergetool
喜欢将一些文件称为本地文件，而将其他文件称为远程文件，但它在这里使用的名称确实非常糟糕。Git中的所有内容都是本地的

重要的是，您想要的文件位于一个很难找到的提交中，因为它也是完全本地的，尽管
git mergetool
将其称为“远程”。恐怕这个答案也会相当长。这是TL；博士：


git stash pop
只是
git stash apply&&git stash drop
。如果应用步骤因合并冲突而失败，则会忽略
删除
步骤，这很好
您想要的文件存储在一个隐藏提交中
如果您仍然有隐藏提交，您可以从那里获取整个文件。由于存在合并冲突，
git stash pop
不会自行删除该隐藏，因此您可能在那里运气不错
只要没有提交结果，您还可以将冲突返回到索引（也称为暂存区域）
如果没有，您可能能够挖掘出隐藏提交，即使您已经显式地
git stash drop
ed了它

如果文件位于索引暂存槽中，则可以使用
git show
检索该文件：

git show :3:path/to/file.ext > /tmp/file.ext.recovered

这将
path/to/file.ext
的slot-3版本提取到标准输出，这里我将其重定向到一个临时文件

或者，如果从存储中找到
w
commit，则可以使用
git show:
查看保存的文件。例如，如果
refs/stash
本身仍然引用
w
commit，则可以轻松运行：

git stash show stash:path/to/file.ext > /tmp/file.ext.recovered

把它拿回来

继续阅读，了解什么是
w
commit，以及如果无法直接从索引中获取所需文件，在必要时如何找到它

长的
首先，让我注意到，
git stash
只是进行和使用提交。运行时：

git stash        # aka "git stash save" or "git stash push"
...
git stash pop

您正在创建一个提交，两个提交，实际上是在保存/推送步骤，然后使用该提交（两个提交之一）在
pop
步骤执行合并操作

因为合并有冲突，所以您需要知道合并实际上是如何工作的。使用
gitmergetool
可以让您暂时推迟了解一些细节，但现在是深入了解它们的时候了

现在，Git中的每个提交都会记录整个源代码树的完整快照。这适用于所有常规提交，也适用于
git stash
进行的特殊提交。事实上，隐藏提交的主要特点是它们不在分支上

树枝是如何生长的，在树枝上意味着什么
在Git的正常操作中，您“在”某些分支上，例如
master
或
developer
。但这究竟意味着什么？好吧，让我们坐下来想象一下，我们正在启动一个全新的、完全空的存储库，根本没有提交。我们在分支
主机上，但没有提交。因此，我们创建一些文件，对它们运行
git add
，然后运行
git commit
，这将创建第一个提交。它会得到一些大的、丑陋的、看似随机的散列ID，但简而言之，让我们称它为commit
A
。现在我们可以得出目前的情况：

A   <-- master

分支名称指向分支上最后一次提交的概念为我们提供了该提交的名称。Git称之为分支的顶端。分支名称总是简单地标识分支上的最后一次提交

一旦进行了提交，就不能以任何方式对其进行更改。（最多，你可以决定你不喜欢
B
，停止使用它，开始使用你喜欢的新提交，它指向，比如说，提交
a
。如果你让
master
这个名字指向
B
的替代品，Git看起来已经改变了
B
，但实际上，提交只是一个不同的提示，w使用新的和不同的散列ID。）因此
A <-B   <-- master

A--B--C--D--E--F   <-- master
          \
           G--H   <-- develop

A--B--C--D--E--F   <-- master
          \
           G--H   <-- develop (HEAD)

A--B--C--D--E--F   <-- master (HEAD)
          \
           G--H   <-- develop

git diff --find-renames <hash-of-D> <hash-of-F>   # what we changed
git diff --find-renames <hash-of-D> <hash-of-H>   # what they changed

A--B--C--D--E--F--I   <-- master (HEAD)
          \      /
           G----H   <-- develop

...--J--K   <-- branch (HEAD)
         \
          i

...--J--K   <-- branch (HEAD)
        |\
        i-w   <-- refs/stash

...--J--K--...--L   <-- branch (HEAD)
        |\
        i-w   <-- refs/stash

git diff --find-renames <hash-of-K> <hash-of-L>   # what "we" did
git diff --find-renames <hash-of-K> <hash-of-w>   # what "they" did