如何提交文件重命名及其内容单独编辑(因此git检测重命名)？

Question

当我澄清代码时，我会重命名和编辑一个文件，以至于git不能将它识别为重命名。

修复:提交旧文件的重命名；然后，提交新文件。

在编辑了这么多之后，我怎么能用git很好地做到这一点呢？

git stash不识别新的文件名。

目前我这样做：

• 将新文件移到其他地方-git reset oldfile以获取旧文件
• 改名
• 投入它
• 现在，取回新文件，覆盖上面的内容。
• 把那件事

我将其描述为一个文件，但通常是多个文件，位于不同的目录中。我不知道你是怎么想的，但对我来说，不小心地改写和丢失新版本是很容易的。现在还没有完成，所以没有reflog救援。

这似乎是git能帮到我的.

编辑:为了reflog安全，我可以将它提交给临时分支。

Answer 1

Git并没有提供一种非常好的方法来实现这一点，但这是可行的。假设：

• foo是文件的旧名称，修改后的文件的名称在磁盘上仍然存在。
• bar是您希望它具有的新名称。
• 索引没有任何变化。

那就做：

git update-index --add --cacheinfo "$(git ls-files --full-name -s foo \
    | awk '{print $1 "," $2 ",bar"}')"
git rm --cached foo
git commit -m "rename foo to bar"
mv foo bar
git add bar
git commit -m "make changes to bar"

git update-index告诉git使用与索引版本foo相同的散列和模式在索引中生成一个新文件，但是使用新的名称bar。它不查阅磁盘，它只是假设一个对象存在于该散列(它确实存在)。git rm --cached告诉git在不接触磁盘的情况下对foo进行移除。他们一起组成一个重命名，我们可以承诺。然后我们实际移动文件，使用git add通知git它的新内容，然后再次提交。当然，您还可以向此提交添加其他更改。

在git update-index和mv之间，git status将显示一个未分阶段的deleted: bar更改，因为该文件存在于索引中，但在磁盘上不存在(至少还没有使用该名称)，但这不是一个问题。

注意，名称bar必须是相对于存储库根的路径，即使您是从子目录操作的。为了简单起见，可以从回购根操作，并为foo和bar使用完整的路径。

所有这些都不像您所做的那样简单，但它确实避免了从工作树中还原更改的需要。

Answer 2

我想这听起来很简单，但是最简单的解决方案是:当你编辑一个文件，有一堆待编辑的文件，然后你决定需要重命名这个文件，

(1)请注意，您需要重命名它(2)使文件处于可以提交更改的状态(3)提交它(4)重命名它(5)提交重命名(6)如果有必要，继续编辑

也就是说-如果您不想在对受影响的文件提交更改的同时提交重命名.那就别这样。

在极少数情况下，可能有理由通过更改来重命名。例如，Java中的公共类名应该与其文件名匹配。但这很好-重命名检测更改阈值(默认情况下)不是100%匹配。小小的改变几乎不会对任何事情造成伤害。但这并不是真正的问题，因为您已经决定要单独提交。

所以现在的问题只是一个小小的计划。现在，您要重命名一个经过很大修改的文件(或者对一个重命名的文件进行重大编辑)，这就是决定“哦，我想把这个下一步与我已经完成的提交工作分开”的时刻。

如果你真的做不到，那么藏起来就好了。保存您的编辑，重命名文件，提交，打开存储。是的，弹出的文件将位于错误的路径上，因此再次重命名它(覆盖原始文件)。

顺便说一句，取决于你的工作流程，这一切都是徒劳的。合并将不会查看单个提交，并且会看到完全相同的情况，就像您在一次提交中完成了所有操作一样。如果您使用一个重基驱动的工作流，您可能会发现它确实有帮助(尽管这有其他的代价)。但总的来说，我要说的是，还有其他策略可以更好地解决这个问题--比如确保发散分支的生存期很短，所以即使在重命名检测不成功的情况下，任何冲突的解决都会保持在最低限度。