Windows EGit-获取、合并、提取故障

好的，就这么定了。
我在我的Debian（lenny）远程服务器上安装了Git。Git版本有1.5.6.5。我打算将其用作远程共享/备份存储库。
我的开发机器运行的是Windows，而我的Eclipse和EGit运行的是Windows。这就是我所做的：

• 为git创建了共享用户
• 设置SSH（在Eclipse和服务器上）、交换公钥等等，一切都进行得很顺利
• 我创建了远程repo，并用git——bare init对其进行了初始化
• 在本地回购中创建了项目，成功地进行了一些更改和提交
• 将主分支从本地repo推送到远程主分支。到目前为止还不错
• （此外，在第三台机器上，我克隆了远程repo（通过EGit导入），没有任何问题。）

“奇怪”的事情开始于我从project中删除了两个文件，然后尝试从remote中拉出，希望恢复删除的项目，因为推送到remote的最后一个快照拥有所有文件。由于pull本质上是fetch+merge，似乎EGit在合并策略方面存在一些已知的问题。尽管如此，我还是配置了fetch，产生了以下fetch规范：

refs/heads/master:refs/remotes/amrtest1/master

Fetch正常，至少看起来是这样，在本地repo中为远程主分支创建了新文件夹，我注意到Fetch_HEAD也在那里。
在签出的本地主分支中，我尝试与远程主分支合并。。。结果是：

• 本地删除的文件未恢复
• 在同步透视图中，我可以看到丢失的文件（在传出模式下？）
• 在EGit的历史视图中，获取操作是在本地提交之前（删除文件之后）按时间顺序执行的，这肯定是不正确的

我做错什么了吗？根据所描述的过程，我对恢复状态的期望是否无效？如果是这样的话，该怎么办（从远程回购恢复状态，或者至少将其与现有本地回购正确合并）

---

谢谢。

是的，你的期望是错误的。事实上，在我理解你相信Git会以某种方式在心理上检测到你不想删除你明确删除的文件并在合并操作中恢复它们之前，我进行了几次重读。如果您想要恢复这些文件，您应该恢复删除它们的提交，或者将文件从其存在的版本复制到当前版本

---

最重要的是，如果您所说的“EGit的历史视图”是正确的，那么可能意味着您已经将pull设置为执行重基，而不是合并。在rebase中，大致假定您自上次拉动以来所做的更改应该像针对上游的当前版本一样应用。对于其他人来说，这通常更容易理解，但如果当时有很多人在更改相同或相关的代码，这可能会让人困惑或彻底失败。

只是为了澄清一点-我没有做拉动，因为它无法进一步发挥作用，我没有做任何提到重基的事情，除非EGite在我不知道的情况下这样做。我所说的“EGit的历史视图”，是指在项目上单击鼠标右键时显示的历史选项卡，即团队>显示历史。在我接受这个答案之前，我必须进行更多的探索