git ls-tree和git ls-files的区别是什么？在git中推送已删除的文件的正确方式是什么？

Question

在我的代码库中，我发现有些文件在 git ls-tree 中不存在，但是在 git ls-files 中存在。我所做的是：

在工作目录中

~/wsp$ git clone ~/repo/project1
~/wsp$ rm project1/file1
~/wsp$ git add -A
~/wsp$ git commit -m'deleted file1'
~/wsp$ git push

在仓库目录中

~/repo$ git log
<deleted file1 commit msg is there>
~/repo$ git ls-tree
<file1 is not in ls-tree>
~/repo$ git ls-files
<file1 is still there!>
~/repo$ find . -name file1
~/repo/file1

看起来，尽管在工作目录中删除了file1并使用git-rm命令将其提交并推送到repo，但file1仍然存在于repo目录中。

我该如何将一个git目录中已删除或重命名的文件推送到另一个git目录中？

提前感谢您的帮助 :)

- kepinpin

---

你正在从 ~/vcs/project1 克隆并推送，为什么要检查 ~/repo？ - Shahbaz

git ls-tree需要你提供一个树对象，如果git ls-tree只显示了使用指南，请确认是否正确提供了树对象。同时，git ls-tree不会递归操作除非你提供了-r选项。 - CB Bailey

如果git ls-files在~/repo中工作，那么这意味着这是另一个非裸克隆~/vcs/project。 您需要合并/重置/变基/检出某些内容，以便从~/wsp推送的更改进入~/repo的工作目录中。 - CB Bailey

@shahbaz 哎呀我的错，已编辑。 - kepinpin

@CharlesBailey 为了澄清，我试图推送到之前克隆过的一个仓库。我发现执行“合并”只会更新树/索引，而不是实际文件，至少对于删除文件的情况如此。 - kepinpin

Answer 1

不要向非裸库推送。您更改了~/repo的存储库状态，但未更改工作目录。当您在repo中运行git status时，您会看到git认为您手动进行了一些更改，因为您的存储库状态与工作目录/索引不匹配。如果您想要消除差异，您需要在repo中运行git reset --hard。但这将清除您在工作目录中所做的任何更改。您不应该首先将其推送到repo。您只应该推送到裸库（没有工作副本的存储库）。您可以从非裸库中拉取。因此，将更改从wsp导入repo的正确方法是进入repo并从wsp中拉取。或者，您是否有特定原因需要将其推送到非裸库？

- Chronial

---

我正在尝试为我的团队设置一个Git仓库。没有特定的原因，我不应该进入'repo'并从'wsp'中拉取。 - kepinpin