2

我有一个 Git 存储库，到目前为止，它主要用于 Windows 开发。Git EOL 问题的大多数方面（LF 与 CRLF）并不重要，开发过程顺利进行。
转移到 CMake 构建环境后，我想在 UNIX/Linux/MacOS 上构建代码。代码本身是可移植的，但从过去的经验和一些初步实验来看，这种转换有点痛苦，因为 Git 将未触及文件上的整个目录标记为已修改，检测文件中看似未修改的行并搞砸区分大小写的文件/文件夹名称。

此外，从 Git 1.7.2开始，Git 似乎有了一个新的 EOL 系统，它基于本地、每个项目、签入，.gitattributes而不是每个用户、全局，.gitattributes每个平台上的每次使用都应该设置。

任何人都可以建议一个回购准备路径/过程（在 Windows 上），它可以让我在 Linux 上拉取和提交文件而不会遇到所有这些麻烦？

可以看到部分建议，例如here，但这太蛮力了，并且没有考虑到.gitattributes专门打算保留原样的文件（例如*.sln）

4

2 回答 2

0

通常，在将数据存储到 VCS 之前不要自动转换数据（git IIRC 中的 autocrlf=false），否则您会误报数据没有发生变化。将数据含义的任何“解释”留给 VCS 之外的工具（编辑器等）。

为了防止虚假的换行更改，请考虑：

  • 设置某种预提交钩子，拒绝任何仅包含重写换行符的更改的提交。
  • 仅保护可能对换行更改敏感的少数文件（.sln、.vc* 文件等）。
  • 弄清楚您的团队正在使用哪些编辑器，并确保每个人都对其进行了配置，以免他们虚假地重写换行符。（默认情况下，大多数编辑器已经设置为这种方式 - 因此，除非有人自行让他们的编辑器重写它们，否则您不会有问题。）
于 2013-08-19T05:44:50.717 回答
0

我使用 Notepad2，您可以将默认行尾更改为 Linux (LF)。

如果我理解正确，实际上不需要将源文件更改为在 Windows 机器上具有 LF。尽管 Git 使用 LF 签入它们，但在 Windows 上可以使用 CRLF 签出它们。

对我来说，这是一个很大的不。使用 git 时，我想准确检查repo 中的内容。当任何体面的 Windows 文本编辑器允许您选择默认行尾时，我认为没有理由使用 git convert 行尾。我不会也不会允许 git 弄乱行尾。

于 2012-12-08T20:41:51.083 回答