所以我在git diff --check文件和add之前运行commit，然后在两个特定文件上运行path/filename:linenumber: new blank line at EOF。如果我删除这些文件中的最后一个空行，我就不会收到任何消息，但我认为使用换行符结束文件是一种很好的方式。奇怪的是，我认为其他文件具有完全相同的结尾，不会给出任何消息。我是git的新手，在OS X Yosemite上使用git 2.0.1。我使用vim作为我的编辑。
如何在避免此消息的同时以换行符结束我的文件？我应该忽略它吗？
答案 0 :(得分：19)
这里有两个问题。
你对＃34;换行符感到困惑＆＃34; vs＆＃34; new line＆＃34;：
A＆＃34;新线＆＃34;是一个实际的空行（仅包含一个＆＃34;换行符和＃34;字符）和一个＆＃34;换行符＆＃34;是一个特殊字符，用于标记当前行的结尾。
大多数编译器，解释器和Unix工具都希望您的文本文件以换行符结束，以避免在处理多个文件时出现歧义，而不是＆＃34;新行＆＃34;。
大多数编辑，包括Vim，在每一行的末尾添加必要的字符，包括最后一行，因此您无需做任何事情以确保满足要求。
特别是没有添加＆＃34;新行＆＃34;在EOF。
你可能习惯了不良行为：
＆＃34;换行符＆＃34;字符传统上被解释为＆＃34;行终止符＆＃34;通过Unix工具，大多数编译器和Vim。这意味着在该角色之后的任何内容都被认为是在另一条线上。由于该字符是文件中的最后一个字符，因此没有理由显示用户不存在的行。
唉，大多数GUI编辑器将其解释为＆＃34;行分隔符＆＃34;，这意味着它标记了两行之间的分隔，并且那些编辑器通常在文件末尾显示不存在的行以满足该行解释
我可能会假设太多，但看起来你已经习惯了那种错误的行为，并试图通过添加一个完全不必要的新线来模仿它。＆＃34;在文件的末尾。
要么继续添加＆＃34;新行＆＃34;在源文件的底部，将其视为某种格式和编码指南，并停止将这些Git消息视为错误消息。
或者你停止添加那些无用的＆＃34;新行＆＃34;。
我会选择第二种选择。
答案 1 :(得分：13)
<强> - 检查
如果更改引入空白错误，则发出警告。什么被认为是空白错误由
core.whitespace配置控制。默认情况下，尾随空格（包括仅由空格组成的行）和在行的初始缩进内紧跟着制表符的空格字符被视为空格错误。如果发现问题，则退出非零状态。与--exit-code不兼容。
<强> core.whitespace
要注意的常见空格问题的逗号分隔列表。 git diff将使用
color.diff.whitespace突出显示它们， git apply --whitespace = error 会将它们视为错误。您可以为-添加前缀以禁用其中任何一个（例如-trailing-space）：
blank-at-eol将行末尾的尾随空格视为错误（默认情况下启用）。
space-before-tab将行的初始缩进部分中的制表符前面出现的空格字符视为错误（默认情况下启用）。
indent-with-non-tab将使用空格字符而不是等效标签缩进的行视为错误（默认情况下未启用）。
tab-in-indent将行首字母缩进部分中的制表符视为错误（默认情况下未启用）。
blank-at-eof将文件末尾添加的空行视为错误（默认情况下启用）。
trailing-space是涵盖blank-at-eol和blank-at-eof的简写。
cr-at-eol将行尾处的回车处理作为行终止符的一部分，即使用它，如果此回车符之前的字符不是a，则不会触发尾随空格空格（默认情况下未启用）。
tabwidth=<n>告诉标签占据多少个字符位置;这与缩进与非制表符相关，当Git修复制表符缩进错误时。默认选项卡宽度为8.允许的值为1到63。
如您所见，默认情况下启用blank-at-eof。您可以通过将-blank-at-eof添加到core.whitespace配置，或者使用您自己的core.whitespace配置来禁用它。