我正试图让git设法“记住”文件的名称及其路径，因为它只存储blob中的文件内容。 Abizem在link here中的解释是好的吗？ （这是迄今为止我见过的最好的）
后续问题是，git如何确定何时具有相似性，尤其是在“移动”或路径名更新后？ （根据我的Q sub-directory renames）。我需要能够维护一个现有的工作流程，该工作流程使用路径重命名作为低级个人VCS的一部分（对于大型版本，我们有一个很大的铁VCS，但是没有用于日常/小时到小时的使用）
答案 0 :(得分：10)
git定义了四种对象（Commit，Tag，Tree，Blob）。在其内容的散列之后标识每个对象。
重命名涉及的三个对象是：
blob：这对应于一个已提交的文件，该对象的内容是原始文件的压缩内容
树：这对应于目录列表，它包含文件名到其他对象（blob或树）的映射，还记录了访问权限
commit：这包含提交消息，指向父提交的指针（第一次提交除外）和树对象
因此，当您重命名文件并提交它时，会创建一个新的树对象（如果它位于子目录中，并且具有一个新的树对象），并且对象具有新的映射名称，但该对象是相同的。
但是，git不会跟踪重命名，它会尝试通过比较文件内容来重新发现它们。如果两个文件非常相似，但名称不同，则认为它是重命名。这可能很耗时，如果有大量文件，它可能会失败。
编辑：看一下Git社区手册，它有一个really good explanation关于git如何存储信息。
答案 1 :(得分：2)
Why does git not "track" renames?
Git必须与很多人进行互操作 不同的工作流程，例如一些 更改可以来自补丁，其中 重命名信息可能不是 可用。依赖于显式重命名 跟踪使得无法合并 两棵树完全完成了 同样的事情，除了一个人做了 补丁（创建/删除），一个人做到了 使用其他一些启发式方法。
在第二个注释中，跟踪重命名是 真的只是一个特殊的跟踪案例 内容如何在树中移动。在一些 在某些情况下，您可能会感兴趣 在查询添加功能时 或移动到另一个文件。只是 依靠重新创造的能力 Git的目标是在需要时提供这些信息 提供更灵活的方式 跟踪树木的变化情况。
然而，这并不代表Git 不支持重命名。差异 Git的机器有支持 自动检测重命名，这个 通过'-M'开关打开 git-diff- *命令族。该 重命名检测机器使用 git-log（1）和git-whatchanged（1），所以 例如，'git log -M'将给出 重命名的提交历史记录 信息。 Git也支持 有限的合并形式 重命名。分配的两个工具 责备，git-blame（1）和 git-annotate（1）都使用自动 重命名检测代码以进行跟踪 重命名。
作为一个非常特殊的案例，'git log' 版本1.5.3及更高版本有'--follow' 允许您关注的选项 给定单一路径时重命名。 Linus就此主题发送的邮件。
Git有一个重命名命令git mv，但是 这只是为了方便。该 效果难以区分 删除文件并添加另一个 不同的名字和相同的 内容。
我很惊讶没有人与Pro Git book相关联。我的大部分经验都来自于此。
另外，如果您可以获得该书Version Control with Git，请执行此操作。这是一本非常好的书，尤其适合初学者
这是链接 - Version Control with Git
还有Git from bottom up。