我在 Windows 7 上使用 Github for Windows,有时它会显示一些文件的粉红色墙,即使该文件根本没有被修改(如下图所示)。我找到了一篇谈论这个的文章,但我没有找到一个好的解决方案。有没有办法让 Github for windows 正常工作,而不是在我的文件中将CRLF字符更改为LF ?我喜欢CRLF ....
2 回答
我喜欢CRLF....
每个人都在 Windows 上做 ;-)
除了 Git 更喜欢在内部存储带有 LF 行尾分隔符的文本内容。
但是,您可以同时拥有:工作目录中的 CRLF 和 git 对象数据库中的 LF。有一个 git 内置机制可以为您提供便利。
事实上,正如Scott Hanselman 的帖子所述,
[...]您可以按照 GitHub for Windows 的建议使用 text=auto (并为每个存储库创建一个.gitattributes文件,其中包含以下行)。
# Auto detect text files and perform LF normalization * text=auto
text=auto是做什么的?
这确保了 git 认为是文本的所有文件都将在存储库中具有规范化 (LF) 行结尾。core.eol 配置变量控制 git 将使用哪些行结尾来处理工作目录中的规范化文件;默认是使用平台的本机行结尾,如果设置了 core.autocrlf,则使用 CRLF。
另一个非常有用的内容是 Tim Clem 的帖子Mind the End of Your Line。这出色地解释了 Git 行尾的原因和方式。
更新
nulltoken,我的项目文件夹中有 .gitattributes,它有 text=auto,但 github 客户端只是一次又一次地向我显示粉红色的墙壁。
在您上面的评论之后,下面还有一些需要考虑的要点。这将需要您切换到命令行才能运行一些 git 命令。
- 确保
.gitattributes
文件已提交,并且不仅位于您的项目文件夹中。 - 为了不丢失任何东西,请确保您没有任何待处理的更改(例如,运行
git status
应该输出类似的内容nothing to commit, working directory clean
) - 运行
git checkout-index --force *
。考虑到文件中的指令,这将在您的工作目录中重新创建所有.gitattributes
文件。完成此操作后,工作目录中的每个文本文件都将以 CRLF 行结尾,并且git status
仍应将 workdir 视为干净的。 - 从现在开始,在创建新提交时不应出现粉墙。
注意:.gitattributes
粉红色的墙可能仍然会出现,同时显示在包含文件的提交之前创建的历史记录中的两个提交之间的更改。
- 在记事本++中打开文件。
- 转到编辑/EOL 转换。
- 单击 UNIX/OSX 格式。
- 保存文件。