我已经使用git多年了，并且总是想知道为什么git diff用/和b /作为修改文件的名称的前缀。我预计最终会偶然发现一个有用的用例，但直到现在它总是很烦人而且从来没用过。
有什么好处？为什么默认启用？在哪些情况下有用？
答案 0 :(得分：44)
如diff man page中所述，a / et b /表示区分来源和目的地的前缀。
实际上，您有以下选项：
--no-prefix
不显示任何源或目标前缀。
--src-prefix=<prefix>
显示给定的源前缀而不是“a /".
--dst-prefix=<prefix>
显示给定的目标前缀而不是“b /”
答案 1 :(得分：27)
如果您觉得它没用，可以使用以下命令将其关闭：
git config --global diff.noprefix true
答案 2 :(得分：13)
这些目录前缀基本上是兼容性的，并被选为合理的默认值。说明如下。
在git（以及其他VCS）之前，为多个文件创建补丁的工作流程可能是，例如，以下内容：
asdf中拥有项目asdf-source.latest的源代码。asdf-source.new，理想情况下hard-linking里面的文件。）asdf-source.new中进行所有更改，尝试编译代码，测试代码等。diff -r asdf-source.latest asdf-source.new >new_feature.patch。产出也随着时间的推移而演变。除了其他东西，git默认使用“统一”输出，可以使用diff的-u参数获取。现在，您可以使用目录名称看到修补程序包含已更改文件的路径。
应用修补程序的人员（或构建脚本等）将使用patch而不是git apply或git am。为了使命令能够找到正确的文件，必须使用patch的-pN选项从路径中删除目录名（N表示要删除的目录名和分隔符的数量）。在上面的例子中，使用的命令可以是patch -p1 <new_feature.patch。这使得补丁创建者可以使用他/她自己的目录名。
如果您遇到过使用大量修补程序修补某个项目的脚本（例如，通常用于Linux发行版中稳定包版本的back-ported修补程序），则修补程序的格式可能会有所不同。
patch命令能够正确检测这些格式，但路径（要删除多少个目录）有点困难。
有些问题：
patch查找文件可能很危险（因为它可能会找到不同的文件）。因此，让每个人发送可以使用patch -p1应用的补丁似乎是最合理的方式。
当创建git时，它采用了合理的默认值（与大多数项目的提交指南（主要是内核）兼容）用于此类选项。多亏了这一点，你可以使用git并将一个格式正确的补丁发送给使用patch来应用它的人，反之亦然（git能够处理diff - 创建的补丁）。将“a”和“b”作为前缀特别节省空间（以及一小部分带宽），同时保持一切正常。
您可以设置git config diff.mnemonicprefix true，以便git根据您的比较使用不同的前缀（有关详细信息，请参阅git help config。）
答案 3 :(得分：6)
区分来源和目的地。您也可以将其更改为更有意义：
- SRC-前缀=
<prefix>Show the given source prefix instead of "a/".- DST-前缀=
<prefix>Show the given destination prefix instead of "b/".
答案 4 :(得分：4)
如果您想手动将git diff --no-prefix添加到 .gitconfig ，只需添加以下内容：
[diff]
noprefix = true