C# 使用Git autocrlf的Sitecore序列化项

序列化项目出现问题。我们的用例是在本地使用自己的数据库，并将所有项目与同步。然后我们将所有项目推送到Git存储库。本地Git配置设置为

autocrlf=true

。这是必要的，因为我们在项目中有一些前端工程师使用Mac OS X。我们使用Unicorn序列化完整的“核心”数据库（如安装后的默认配置）

核心数据库中的某些项似乎是使用非Windows系统创建的。如果我们查看项目

/sitecore/system/Dictionary/O/一个或多个项目已更改，是否要覆盖这些更改
：当我序列化此项目并查看它时，我看到
键
字段包含多行，并且换行符标记为“
\n
”并且
内容长度
为
77
（请参见所附的记事本++屏幕截图，左侧）。在此之后，我将该文件推送到Git存储库，并从存储库中从另一个工作站上提取该项目。由于设置了
autocrlf=true
，“
\n
”将自动转换为“
\r\n
”，这将导致
内容长度
为
79
，而不是原来的
77
（请参见所附屏幕截图的右侧）。当我想要反序列化这个项目时，我得到一个异常，内容长度不匹配


以前有没有人犯过这样的错误？你是如何避免的？我看到了禁用
autocrlf
或从序列化同步中排除这些项的选项。但我希望避免使用这些选项之一。
您可以从文件中控制该行为

在我的属性文件中，.item文件被设置为二进制文件

这是我在项目中使用的.gittributes文件

* text=auto

# These files are text and should be normalized (convert crlf => lf)
*.cs      text diff=csharp
*.xaml    text
*.csproj  text
*.sln     text
*.tt      text
*.ps1     text
*.cmd     text
*.msbuild text
*.md      text

# TDS files should be treated as binary
*.item -text

这并不能回答你的问题，但我一直不明白
autocrlf
的好处。Win/Lin/Mac的角度似乎是一个薄弱的论点，因为任何一个半途而废的文本编辑器都可以处理来自其他操作系统的行尾
autocrlf
只会给我带来麻烦。此解决方案也适用于TDS。第一次切换到Git时，我们遇到了很多麻烦（w/TDS items），直到我们了解了这个技巧。TDS中的.item文件只是标准sitecore项序列化中的文件。