我有一个文件a.java，我已经对其进行了修改。
同时，在我将更改推送到master之前，另一位开发人员删除了该文件（基本上将其重命名为软件包）。
现在，当我重新进行更改基准时，我看到了
Unmerged paths:
deletedbyus: a.java
现在，由于我想保留更改，所以我做了..我尝试了git add a.java，但是我仍然看到它似乎不起作用
Unmerged path:
deltedbyus: a.java
如果我执行git rm或rm，则将暂存该文件，但它将显示为已删除，从而将其全部删除。
在完整保存我的更改的情况下恢复文件的正确方法是什么。
答案 0 :(得分：0)
假设您在master分支上，并且其他人将a.java文件的 package更改推送到master，现在您正在做{{1提交更改后，在git rebase分支上的}}中，我们来弄清它的确切含义：
在这种情况下，git将您的master分支的HEAD重置为远程master分支之一。然后git接受每个实际的您的提交，并将它们重写到新的主origin/master之上。
实际上它们是您正在重写的 提交，但是从git的角度来看，它们是 them 的更改，因为它们属于分支git在最基础上的当前分支（实际上不是您的更改，但现在是我们的 分支，因此是我们的更改）。
在这种情况下，当git告诉您HEAD时，这意味着在落实git中，该文件再次存在 ，因为该文件已在我们的分支中被删除 （由我们），但是我（git）如何处理对不再存在的文件的更改？有人故意删除了该文件，而我（git）无法在没有该文件的情况下再次创建该文件确认（确实是正确的）。
那么，您应该怎么解决这种情况？实际上，您应该在文件现在存在的位置（在新包中，假设您想保留）中包含您的更改（在重新设置基准期间，从git的角度来看，其）包装变更）。完成此操作后，您应该
deletedbyus但是，您对文件进行了哪些更改？您可以通过# Manually carry the changes you made to
# file/on/old/package/a.java
# to file/moved/to/new/package/a.java
git add file/moved/to/new/package/a.java # To confirm your changes
git rm file/on/old/package/a.java # To confirm deletion
git rebase --continue # To continue with your rebase