如果文件的名称和内容已更改，是否可以在提交后标记移动？
EG
file1.txt改为file2.txt，内容发生了变化。git commitfile1.txt已被删除，file2.txt是一个不相关的新文件。在提交发生后，有没有办法将此标记为重命名？
不，它不是，因为Git没有重命名跟踪...但它确实重命名检测 （基于文件内容和名称的相似程度）。
这意味着
git log --follow file2.txt将通过重命名来跟踪文件历史记录（注意：遗憾的是，这并不总是正常工作，因为--follow有点破解），git blame -C -C file2.txt将遵循文件重命名，内容复制以及跨文件和内部文件移动的逐行文件历史记录git show -C将显示文件重命名（您可以将Git配置为始终重命名，并且可选择在显示差异时进行复制检测）。HTH
正如您所发现的那样，git不会检测到真正实质性更改和同时移动重命名的组合。
要理解的是，每次查看历史记录时，git都会通过将提交的内容与其父提交进行比较来检测提交中的更改。这似乎太简单了，但事实证明这很简单。
因此，您需要插入一个新的提交，git log等可以检测到的重命名，然后是您从那时起累积的其余历史记录，这意味着您的分支的新历史记录，即rebase或cherry -挑。
所以：
# make a new history with a rename that can be detected by comparing commits
# check out the glitched commit's ancestor by its sha,
# this work won't take enough time to bother inventing a transient name for it
git checkout commit-before-rename+bigchange
git mv file1.txt file2.txt
git commit
git checkout commit-with-rename+bigchange -- file2.txt
git commit
# Now add the rest of the changes, also detectable by comparing commits,
# by re-applying them on top of this new history:
git cherry-pick commit-before-rename+bigchange..branch-it\'s-on
# and force the old branch name to refer to this new history you just made
# the old history will be garbage-collected after 90 days or so if
# it's not part of the history of any other references
git checkout -B branch-it\'s-on
而且你已经完成了，除非任何其他存储库通过获取或推送或克隆获得了混乱的历史记录，那么你将不得不强制推送或让那些repo的所有者强制重新获取（以及任何后续历史记录他们'我建立在那之上，这就是为什么你真的不想发布太快的原因）。
不，那里没有。 Git没有任何文件标识的概念。它存储目录树的内容。只有树作为一个整体才有历史概念。
只有一个原因可以跟踪文件是否已重命名而不是旧文件已删除，并且添加了新文件，这是为了允许合并该文件中的更改。由于您更改了文件（超出重命名检测认为的类似），因此无法在没有冲突的情况下合并更改，因此应该没有实际区别。
请注意，Git通过搜索类似文件来处理合并原因。它在git status和所有合并中自动完成，并在git log，git diff和其他命令显示更改，如果你要求它。如果找不到重命名，则不太可能进行合并。