我该如何解决这种“鸡与蛋”的情况？
我决定在 Eclipse 中重命名一个 Java 类（例如，从 one.java 到 two.java）。 Eclipse 重构让我可以毫不费力地做到这一点。
然后，我去git并输入：
git mv myproj/src/com/ate/lib/one.java myproj/src/com/ate/lib/two.java
并收到错误：
fatal: bad source, source=myproj/src/com/ate/lib/one.java, destination=myproj/src/com/ate/lib/two.java
我明白为什么会发生这种情况，但如果我在 重构之前进行git mv，Eclipse 将不会 像这样......
解决这个问题的好方法是什么？
【问题讨论】：
标签： eclipse git refactoring
git mv 只是一种方便的方法。 git does not "track" renames（也就是说，它可以检测到它们，但它们不会被记录为添加或删除之类的操作）。暂存并提交重构：
git rm myproj/src/com/ate/lib/one.java
git add myproj/src/com/ate/lib/two.java
git commit
git rm 告诉 git 分阶段删除索引中的文件。尽管您已经在工作目录中“删除”了该文件（通过移动它），但您还没有告诉 git 您要对这个删除进行版本控制。 rm 和 git rm 之间的区别在于第一个在工作目录上工作，第二个也在索引上工作（更改由 git 版本控制）。
git add 只是将文件内容添加到新位置。
编辑：
我以前有git rm --cached，出于个人习惯，但如果工作目录中不存在该文件，git rm 显然不会抱怨。 git rm --cached 在您想在版本控制中删除文件但将文件保留在工作目录中时仍然有用。
【讨论】：
--cached - 如果文件不在工作树中，git rm 不会抱怨。
git add 部分，但是当git status 已经报告deleted: myproj/src/com/ate/lib/one.java 时，为什么我需要运行git rm？
git rm 告诉 git 你要删除该文件。 git status 报告该文件已在工作目录中删除，而不是您已对其删除进行了版本控制。如果启用了颜色，“deleted”会变成红色，表示变更已经发生但没有暂存，git rmdeleted 后会贪婪表示变更已经暂存。