跨平台 git 配置的最佳实践？

Best practices for cross platform git config?

提问by Bas Bossink

Context

语境

A number of my application user configuration files are kept in a git repository for easy sharing across multiple machines and multiple platforms. Amongst these configuration files is .gitconfigwhich contains the following settings for handling the carriage return linefeed characters

我的一些应用程序用户配置文件保存在一个 git 存储库中，以便在多台机器和多个平台之间轻松共享。在这些配置文件中.gitconfig，包含以下用于处理回车换行符的设置

[core]
    autocrlf = true
    safecrlf = false

Problem

问题

These settings also gets applied on a GNU/Linux platform which causes obscure errors.

这些设置也适用于 GNU/Linux 平台，这会导致模糊的错误。

Question

题

What are some best practices for handling these platform specific differences in configuration files?

处理配置文件中这些平台特定差异的最佳实践是什么？

Proposed solution

建议的解决方案

I realize this problem could be solved by having a branch for each platform and keeping the common stuff in master and merging with the platform branch when master moves forward. I'm wondering if there are any easiersolutions to this problem?

我意识到这个问题可以通过为每个平台设置一个分支并在 master 中保留公共内容并在 master 前进时与平台分支合并来解决。我想知道这个问题是否有更简单的解决方案？

采纳答案by VonC

I have reviewed that kind of config setting (crlf) extensively in the question:
distributing git configuration with the code.

我已经crlf在问题中广泛地了这种配置设置 ( )：
使用代码分发 git 配置。

The conclusion was:

结论是：

• checkout/checking .gitattributesfiles
• list all types which explicitly need that kind of conversion.
  For instance:

• 结帐/检查 .gitattributes文件
• 列出所有明确需要这种转换的类型。
  例如：

*.java +crlf
*.txt +crlf
...

• avoid doing any kind of conversion of type of files which don't need it, because of the various side-effect of such a conversion on merges, git status, shell environment and svn import(see "distributing git configuration with the code" for links and references).
• avoid any crlfconversion altogether if you can.

• 避免对不需要的文件类型进行任何类型的转换，因为这种转换对合并git status、shell 环境和svn import（请参阅“使用代码分发 git 配置”以获取链接和参考）的各种副作用.
• crlf如果可以，请完全避免任何转换。

---

---

Now, regarding the specific issue of per-platform settings, branch is not always the right tool, especially for non-program related data (i.e; those settings are not related to what you are developing, only to the VCS storing the history of your development)

现在，关于每个平台设置的具体问题，分支并不总是正确的工具，尤其是对于非程序相关的数据（即；这些设置与您正在开发的内容无关，仅与存储您的历史记录的 VCS 相关）发展）

As stated in the question Git: How to maintain two branches of a project and merge only shared data?:

如问题Git：如何维护项目的两个分支并仅合并共享数据中所述？：

your life will be vastly simpler if you put the system-dependent code in different directories and deal with the cross-platform dependencies in the build system (Makefiles or whatever you use).

如果您将依赖于系统的代码放在不同的目录中并处理构建系统（Makefile 或您使用的任何东西）中的跨平台依赖项，您的生活将变得更加简单。

In this case, while branches could be use for system-dependent code, I would recommend directory for support tools system-dependent settings, with a script able to build the appropriate .gitattributesfile to apply the right setting depending on the repo deployment platform.

在这种情况下，虽然分支可用于系统相关代码，但我会推荐支持工具系统相关设置的目录，脚本能够构建适当的.gitattributes文件以根据 repo 部署平台应用正确的设置。

回答by hasen

Never turn autocrlfon, it causes nothing but headaches and sorrows.

永远不要打开autocrlf，它只会引起头痛和悲伤。

There's no excuse to use \r\non windows, all decent editors (by definition) can handle \n.

没有理由\r\n在 Windows上使用，所有体面的编辑器（根据定义）都可以处理\n.

回答by Makis

I think you should have the .gitconfig depend on the operating system the user is using. Windows users don't need autocrlf at all while Linux users do. E.g. save the text files with crlf and have Git convert the files automatically back and forth for the Linux users.

我认为你应该让 .gitconfig 取决于用户使用的操作系统。Windows 用户根本不需要 autocrlf，而 Linux 用户则需要。例如，使用 crlf 保存文本文件，并让 Git 自动为 Linux 用户来回转换文件。

You might also want to check .gitattributes, which allows you to define which files are converted and which are not. If you have the configuration files in just one place, you could define that the conversion is only done in that directory just to be on the safe side.

您可能还想检查.gitattributes，它允许您定义哪些文件被转换，哪些没有。如果您只有一个地方有配置文件，您可以定义转换仅在该目录中完成，以确保安全。