我有一个远程 SVN 存储库和一个本地 git 存储库。使用 git-svn 我已将 git 链接到 SVN 并成功使用git svn rebase,git svn dcommit来拉取和推送到远程 SVN 存储库。
但是，当其他人检查我以前用 git 编辑过的文件SVN并尝试在 VS2010 中打开它们时，他们会收到一个对话框，告诉他们行尾不一致。
我已经阅读了一些关于core.safecrlfgit config 中的选项的内容，但这能解决我的问题吗？我有很多其他人在签到，但我们都在运行窗口 - 我认为行尾是一样的？
设置会core.safecrlf在结帐和提交时保留相同类型的行结束吗？
我最近一直在处理同样的问题。默认情况下，Windows 上的 Git 设置core.autocrlf = true。发生的情况是，您的文件是从带有 CRLF 行结尾的 SVN 存储库中签出的，但使用 unix 样式 (LF) 行结尾提交。当您提交这些更改时，我相信这些文件也会以 unix 样式的行结尾被推送到 SVN 服务器。现在，当有人使用 SVN 签出这些文件时，不会执行行结束转换。
您可以设置core.autocrlf = false以便不进行任何转换。如果您都在 Windows 中工作，那么您应该没有任何问题。如果您与 *nix 用户共享 SVN 存储库，那么您很可能会开始出现不一致。这就是 autocrlf 选项的原因。repos 应该保持一致，并且由于 Linux 不喜欢与 CRLF 很好地配合使用，所以这个 autocrlf 应该设置为 true。
行尾问题是 git-svn 众所周知的头痛问题。我建议使用SmartGit来处理您的存储库。我尊重 svn:eol 样式的值，以便在 Git 中使用正确的 EOL（将其转换为相应的 .gitattirbutes 值）。您还可以通过适当的更改 .gitattirbutes 来控制推送到 SVN 的 svn:eol 样式值。
如果您可以访问服务器，则可以使用另一种方法：只需将SubGit安装到您的 SVN 服务器中。然后将在服务器上创建一个链接的 Git 存储库，以便每次推送到它都会自动转换为 SVN，反之亦然。它还将 svn:eol-style 转换为 .gitattirbutes。
所以我会推荐其中一种解决方案，但不是 git-svn，它（据我所知）在 Windows 上非常缓慢。
这是一篇 GitHub 文章，描述了您在 Git 中处理行尾字符的选择：
https://help.github.com/articles/dealing-with-line-endings
本质上，Git 有助于在不同操作系统上转换 EOL。SVN 也有类似的功能。您需要确保以一致的方式设置它们。