Git No newline at end of file

一 问题发生

在使用git命令git diff时，内容的末尾出现了“\ No newline at end of file”，即在文件的末尾没有文件换行符。如下图所示：

二 问题分析

　　文件的末尾没有文件换行符，似乎没有什么问题。但是仔细思考，就会发现问题所在。文本文件内容的修改是基于行定位的，也就是说对于某行添加或者删除了若干字符，git无法定位到这些字符的改动。针对此行来说，前后内容变化了，git理解为先删除修改前的此行后添加修改后的此行。

　　于是，问题产生了。由于行的末尾没有换行符，如果我们想在新的一行上添加内容，首先要输入换行符。原来没有换行符，现在添加了换行符，那么这一行的内容就发生了改变，就会先删除原来没有换行符的“行”，添加有换行符的行。

举个例子，文本文件内容开始为hello world（没有换行符），然后想在新行上添加内容，输入了换行符。（试验环境：Windows10系统，notepad++编辑器）

内容上并不影响，但是不符合逻辑。

因此建议：在编辑文件时（尤其是Windows系统上），在文件末尾的行上手动添加换行符。

三 相关知识

参考链接

Unix历史上有一个所有人类可读的文本文件都以换行符结尾的约定。当时，这避免了在显示或连接文本文件时进行额外的处理，并避免了将文本文件与包含其他类型数据的文件(例如原始二进制数据，这是人类无法读取的)进行不同的处理。

由于这种惯例，那个时代的许多工具都期望换行结束，包括文本编辑器、差异化工具和其他文本处理工具。Mac OS X是在BSD Unix上构建的，Linux是为与Unix兼容而开发的，因此两个操作系统都继承了相同的约定、行为和工具。

Windows并没有开发成与Unix兼容，所以它没有相同的约定，而且大多数Windows软件都会处理得很好，没有后继的换行符。但是，由于Git首先是为Linux开发的，并且许多开源软件都建立在与Unix兼容的系统上，如Linux、Mac OS X、FreeBSD等，因此大多数开源社区及其工具(包括编程语言)继续遵循这些约定。

有一些技术原因在1971年是有意义的，但在这个时代，它主要是传统的，并保持与现有工具的兼容性。