189 8069 5689
这篇文章将为大家详细讲解有关GIT换行符相关操作是什么，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
成都创新互联专注于阿图什企业网站建设,成都响应式网站建设,电子商务商城网站建设。阿图什网站建设公司,为阿图什等地区提供建站服务。全流程按需开发，专业设计，全程项目跟踪，成都创新互联专业和态度为您提供的服务
关于“回车”（carriage return）和“换行”（line feed）这两个概念的来历和区别。在计算机还没有出现之前，有一种叫做电传打字机（Teletype Model 33）的玩意，每秒钟可以打10个字符。但是它有一个问题，就是打完一行换行的时候，要用去0.2秒，正好可以打两个字符。要是在这0.2秒里面，又有新的字符传过来，那么这个字符将丢失。
于是，研制人员想了个办法解决这个问题，就是在每行后面加两个表示结束的字符。一个叫做“回车”，告诉打字机把打印头定位在左边界；另一个叫做“换行”，告诉打字机把纸向下移一行。
后来，计算机发明了，这两个概念也就被般到了计算机上。那时，存储器很贵，一些科学家认为在每行结尾加两个字符太浪费了，加一个就可以。于是，就出现了分歧。Unix系统里，每行结尾只有“<换行>”，即“\n”；Windows系统里面，每行结尾是“ <回车><换行>”，即“\r\n”；Mac系统里，每行结尾是“<回车>”。一个直接后果是，Unix/Mac系统下的文件在Windows里打开的话，所有文字会变成一行；而Windows里的文件在Unix/Mac下打开的话，在每行的结尾可能会多出一个^M符号。
Windows创建的文件是 \n\r结束的， 而Linux等类Unix操作系统是\n结束的。所以Unix的文本到Windows会出现换行丢失（ultraedit这类软件可以正确识别）； 而反过来就会出现^M的符号了
Windows等操作系统用的文本换行符和Unix/Linux操作系统用的不同，Windows系统下输入的换行符在Unix/Linux下不会显示为“换行”，而是显示为 ^M 这个符号（这是Linux等系统下规定的特殊标记，占一个字符大小，不是 ^ 和 M 的组合，打印不出来的）。Linux下很多文本编辑器（命令行）会在显示这个标记之后，补上一个自己的换行符，以避免内容混乱（只是用于显示，补充的换行符不会写入文件，有专门的命令将Windows换行符替换为Linux换行符）。 Unix/Linux系统下的换行符在Windows系统的文本编辑器中会被忽略，整个文本会乱成一团。
Git 的“换行符自动转换”功能听起来似乎很智能、很贴心，因为它试图一方面保持仓库内文件的一致性（UNIX 风格），一方面又保证本地文件的兼容性（Windows 风格）。但遗憾的是，这个功能是有 bug 的，而且在短期内都不太可能会修正。
问题具体表现在，如果你手头的这个文件是一个包含中文字符的 UTF-8 文件，那么这个“换行符自动转换”功能 在提交时是不工作的（但签出时的转换处理没有问题）。我猜测可能这个功能模块在处理中文字符 + CRLF 这对组合时直接崩溃返回了。
例子： 你在 Windows 下用默认状态的 Git 签出一个文件，写了一行中文注释（或者这个文件本来就包含中文），然后存盘提交……不经意间，你的文件就被毁掉了。 因为你提交到仓库的文件已经完全变成了 Windows 风格（签出时把 UNIX 风格转成了 Windows 风格但提交时并没有转换），每一行都有修改（参见本文开头的示意图），而这个修改又不可见（大多数 diff 工具很难清楚地显示出换行符），这最终导致谁也看不出你这次提交到底修改了什么。 这还没完。如果其他小伙伴发现了这个问题、又好心地把换行符改了回来，然后你又再次重演上面的悲剧，那么这个文件的编辑历史基本上就成为一个谜团了。 由于老外几乎不可能踩到这个坑，使得这个 bug 一直隐秘地存在着。
多平台，多 IDE，团队协作，跨平台开发，这是大多数项目都会面临的问题，所以防患于未然，要在项目之初就统一好换行符（项目中技术管理是一门艺术啊！）。
团队需要确定一个统一的换行符标准（推荐使用 UNIX 风格，因为 Git 就是使用 UNIX 换行符）
前期准备工作：配置好使用的代码编辑器与 IDE达到两项标准：
在新建文件时默认使用团队统一的换行符标准
在打开文件时保持现有换行符格式不变（不要做自动转换）
关闭之后，Git 就不会对你的换行符做任何手脚了，你可以完全自主地、可预期地控制自己的换行符风格。
下面主要针对不同的 Git 客户端，分别介绍一下操作方法。
由 Git 官方出品，在安装时就会向你兜售“换行符自动转换”功能，估计大多数人在看完华丽丽的功能介绍之后会毫不犹豫地选择第一项（自动转换）。请千万抵挡住诱惑，选择最后一项（不作任何手脚）。
如果你已经做出了错误的选择，也不需要重新安装，可以直接使用命令行来修改设置。很简单，直接打开这货自带的命令行工具 Git Bash，输入以下命令，再敲回车即可： git config --global core.autocrlf false
TortoiseGit 作为主力客户端，实际上是基于 Git for Windows 的一个 GUI 外壳，你在 Git for Windows 所做的设置会影响 TortoiseGit 的配置。
若未安装 Git for Windows，可在 Windows 资源管理器窗口中点击右键，选择“TortoiseGit → Settings → Git”，进行设置。
GitHub 的 Windows 客户端实际上也是一个壳，它自带了一个便携版的 Git for Windows。这个便携版和你自己安装的 Git for Windows 是相互独立的，不过它们都会使用同一个配置文件（实际上就是当前用户主目录下的 .gitconfig 文件）。
所以如果你已经配置好了自己安装的 Git for Windows，那就不用操心什么了。但如果你的机器上只装过 GitHub 的 Windows 客户端，那么最简单的配置方法就是手工修改配置文件了。
进入当前用户的主目录，修改 .gitconfig 文件
在 [core] 区段找到 autocrlf，将它的值改为 false。如果没找到，就在 [core] 区段中新增一行： autocrlf = false
事实上上面介绍的所有命令行或图形界面的配置方法，最终效果都是一样的，因为本质上都是在修改这个配置文件。
关闭了换行符自动转换，担心文件中带入了 Windows 的回车换行符，Git 为防止这种你的失误，提供了换行符检查功能（core.safecrlf），可以在提交时检查文件是否混用了不同风格的换行符。这个功能的选项如下：
false - 不做任何检查
warn - 在提交时检查并警告
true - 在提交时检查，如果发现混用则拒绝提交
我建议使用最严格的 true 选项。
和 core.autocrlf 一样，你可以通过命令行、图形界面、配置文件三种方法来修改这个选项。具体操作就不赘述了，大家自己举一反三吧。
改为 Unix 风格的换行符
关于GIT换行符相关操作是什么就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。