git diff的/ a / b前缀是什么原因？
我一直在使用git了好几年了，总是想知道为什么git diff会用/和b /作为前缀名。 我预计最终会偶然发现一个有用的用例，但直到现在，它总是令人讨厌，从来没有帮助。
到底有什么好处呢？ 为什么默认启用？ 在哪些情况下有用？
正如差异手册页所述 ，a / et b /表示区分源和目的地的前缀。
其实，你可以select：
--no-prefix 不要显示任何来源或目的地前缀。
--src-prefix=<prefix>
显示给定的源前缀而不是“a /”。
--dst-prefix=<prefix>
显示给定的目标前缀而不是“b /”
如果您觉得没有用处，可以closures它：
git config --global diff.noprefix true
这些目录前缀基本上是为了兼容性，并作为一个合理的默认select。 解释如下。
在git之前
在git（和其他VCS ）之前，为多个文件创build补丁的工作stream可能是如下所示：
- 假设您在目录
asdf-source.latest中有一个项目asdf的源代码。 - 你把目录复制到一个新的目录（例如
asdf-source.new，理想的是硬连接里面的文件）。 - 现在，您可以在
asdf-source.new进行所有更改，尝试编译代码，testing代码等。 - 完成后，使用例如
diff -r asdf-source.latest asdf-source.new >new_feature.patch创build一个补丁。 产出也随着时间演变。 除了其他的东西，git默认使用“统一”输出，这可能是使用diff的-u参数获得的。
现在，您可以看到该修补程序有使用目录名称更改文件的path。
那么应用你的补丁的人（或者构build脚本等）将会使用patch而不是使用git apply或者git am 。 为了使命令find正确的文件，必须使用patch的-pN选项（N显示要删除的目录名称和分隔符的数量）从path中删除目录名称。 在上述情况下，使用的命令可能是patch -p1 <new_feature.patch 。 这使得修补程序创build者可以使用他/她自己的目录名称。
如果您遇到使用大量补丁修补某个项目的脚本（通常用于Linux发行版中的稳定版本的后端端口修补程序），则修补程序可能会有所不同。 patch命令能够正确地检测这些格式，但是对于path有多难（需要删除多less个目录）。 有些问题：
- 强迫开发人员使用0目录不是很好。
- 有
patch查找文件可能是危险的（因为它可能会发现一个不同的文件）。
所以每个人发送可以用patch -p1应用的patch -p1似乎是最明智的方法。
回到混帐
当创buildgit时，它会采用合理的默认设置（与大多数项目的提交准则兼容，主要是内核），以供select。 多亏了这个，你可以使用git，并将正确格式的补丁发送给使用patch人，反之亦然（git也能够处理diff -created补丁）。 具有“a”和“b”作为前缀特别节省空间（以及极小的带宽百分比），同时保持所有的工作。
你可以将git config diff.mnemonicprefix true设置为git config diff.mnemonicprefix true ，以便git使用不同的前缀，具体取决于你正在比较的内容（更多细节参见git help config ）。
这是区分来源和目的地。 您也可以将其更改为更有意义的：
–src-prefix =
<prefix>Show the given source prefix instead of "a/".–dst-prefix =
<prefix>Show the given destination prefix instead of "b/".
如果您想手动添加git diff --no-prefix到您的.gitconfig ，只需添加以下内容：
[diff] noprefix = true
