跨平台 git 配置的最佳实践？
。
我的许多应用程序用户配置文件都保存在 git 存储库中，以便在多台机器和多个平台之间轻松共享 这些配置文件中有 .gitconfig，其中包含以下用于处理回车换行字符的设置。
[core]
autocrlf = true
safecrlf = false
问题
这些设置也适用于 GNU/Linux 平台，这会导致模糊错误。
问题
处理配置文件中这些平台特定差异的最佳实践有哪些？
建议的解决方案
我意识到这个问题可以通过为每个平台建立一个分支并将通用内容保留在 master 中并在 master 向前移动时与平台分支合并来解决。我想知道这个问题是否有任何更简单的解决方案？
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 .gitconfig which contains the following settings for handling the carriage return linefeed characters
[core]
autocrlf = true
safecrlf = false
Problem
These settings also gets applied on a GNU/Linux platform which causes obscure errors.
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 easier solutions to this problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
永远不要打开
autocrlf，它只会带来头痛和悲伤。没有理由在 Windows 上使用
\r\n，所有像样的编辑器（根据定义）都可以处理\n。Never turn
autocrlfon, it causes nothing but headaches and sorrows.There's no excuse to use
\r\non windows, all decent editors (by definition) can handle\n.我已经在问题中广泛审查了这种配置设置（
crlf）：使用代码分发 git 配置。
结论是：
例如：
git status、shell 环境和产生各种副作用svn import（请参阅“使用代码分发 git 配置< /a>”用于链接和参考）。crlf转换。现在，关于每平台设置的具体问题，分支并不总是正确的工具，特别是对于非程序相关的数据（即，这些设置与您正在开发的内容无关，仅与您正在开发的内容相关） VCS 存储您的开发历史）
如问题 Git：如何维护一个项目的两个分支并仅合并共享数据？:
在这种情况下，虽然分支可以用于系统相关的代码，但我建议使用支持工具系统相关设置的目录，并使用能够构建适当的 .gitattributes 文件来应用正确设置的脚本取决于存储库部署平台。
I have reviewed that kind of config setting (
crlf) extensively in the question:distributing git configuration with the code.
The conclusion was:
For instance:
git status, shell environment andsvn import(see "distributing git configuration with the code" for links and references).crlfconversion altogether if you can.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)
As stated in the question Git: How to maintain two branches of a project and merge only shared data?:
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.我认为你应该让 .gitconfig 取决于用户使用的操作系统。 Windows 用户根本不需要 autocrlf，而 Linux 用户则需要。例如，使用 crlf 保存文本文件，并让 Git 自动为 Linux 用户来回转换文件。
您可能还想检查 .gitattributes ，它允许您定义哪些文件被转换，哪些不被转换。如果配置文件仅位于一个位置，为了安全起见，您可以定义仅在该目录中完成转换。
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.
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.