如何在跨平台兼容性的Git提交中强制一致的行尾 [英] How to force consistent line endings in Git commits with cross-platform compatibility

问题描述

在与使用其他OS的人一起工作时，由于行尾而导致合并冲突，我遇到了问题.我在Windows上工作，而我的同事在Mac上.当他进行更改时，有时他未处理的文件会在diff中显示为已更改，因为现在行尾在每个文件上都显示^M.这导致合并冲突.我在Git文档中阅读了以下内容:

I am having issues with merge conflicts due to line endings while working with someone who uses a different OS. I work on Windows and my colleague is on Mac. When he pushes his changes, sometimes files he hasn't worked on show up in the diff as being changed, because the line endings now show ^M on each file. This has lead to merge conflicts. I read in the Git docs the following:

当出现以下情况时，Git可以通过将CRLF行尾自动转换为LF来解决此问题 您将文件添加到索引，反之亦然，当它签出代码时 到您的文件系统上.您可以使用 core.autocrlf设置.如果您使用的是Windows计算机，请将其设置为 true —当您签出代码时，这会将LF结尾转换为CRLF:

Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you’re on a Windows machine, set it to true — this converts LF endings into CRLF when you check out code:

$ git config --global core.autocrlf true如果您使用的是Linux或macOS 使用LF行尾的系统，那么您不希望Git 签出文件时自动将它们转换；但是，如果 意外引入带有CRLF结尾的文件，那么您可能需要 用Git修复它.您可以告诉Git在提交时将CRLF转换为LF，但是 通过将core.autocrlf设置为input来实现:

$ git config --global core.autocrlf true If you’re on a Linux or macOS system that uses LF line endings, then you don’t want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. You can tell Git to convert CRLF to LF on commit but not the other way around by setting core.autocrlf to input:

$ git config --global core.autocrlf输入此设置将使您离开 Windows结帐中的CRLF结尾，而macOS和Windows上的LF结尾 Linux系统和存储库中.

$ git config --global core.autocrlf input This setup should leave you with CRLF endings in Windows checkouts, but LF endings on macOS and Linux systems and in the repository.

这是有道理的，但是我仍然不清楚文件在回购中实际上是如何提交的.例如，如果他在系统上创建了一个文件，该文件将具有所有LF行尾，对吗?因此，当他提交时，我认为这些行尾按原样保留.据我所知，当我拉动时，我的autocrlf是true会检出它们的CRLF行尾. (我收到警告warning: LF will be replaced by CRLF in <file x>; The file will have its original line endings in your working directory)

This makes sense, but I am still unclear on how the files are actually committed in the repo. For example, if he creates a file on his system, it will have all LF line endings, correct? So when he commits, I presume those line endings are retained as-is. When I pull, my autocrlf being true will check them out with CRLF line endings, as far as I understand. (I get the warnings warning: LF will be replaced by CRLF in <file x>; The file will have its original line endings in your working directory)

关于此的几个问题:警告显示工作目录"时，该指的是什么?另外，当我随后进行更改或创建其他文件时，所有这些文件均具有CRLF行尾且具有commit + push，它们是否以CRLF或LF的形式存储在存储库中?

A couple questions about this: when the warning says "working directory", what is that referring to? Also, when I then make changes, or create other files, all of which have the CRLF line endings and commit+push, are they stored in the repo as CRLF or LF?

我想理想的是每次提交时都使回购条带不包含LF.这是怎么回事?幕后到底发生了什么，我们怎么能迫使它保持一致?

I imagine the ideal is to have the repo strip anything but LF everytime a commit is made; is this what happens? What's going on under the hood and how can we force this to behave consistently?

推荐答案

Q1强制执行一致的行尾

Q1 Enforcing consistent lineendings

第二季度在提交和签出(评论)时执行

Q2 Enforcing at commit as well as checkout (comment)

我将其分为两部分:实践和原理

I'll divide this into 2 parts: Practice and Principle

扩展代码学徒的建议

1. 严格避免使用autocrlf-了解为什么 autocrlf总是错误的. 而此处用于核心git开发人员在争论autocrlf的不良思想.特别要注意的是，实施者对 critic 感到恼火，但并不否认 criticism .
2. 宗教上使用.gitattributes代替
3. 使用safecrlf=true强制执行提交清洁度. safecrlf是您Q2的答案–如果文件在签入-签出往返过程中发生更改，则会在签入阶段本身出错.

1. Strictly avoid autocrlf — See why autocrlf is always wrong. And here for the core git devs arguing about the ill-thoughtout-ness of autocrlf. Note particularly that the implementor is annoyed at the critic but doesn't deny the criticism.
2. Religiously use .gitattributes instead
3. Use safecrlf=true to enforce commit-cleanliness. safecrlf is the answer to your Q2 – a file that would change on check-in check-out round tripping would error out on the check-in stage itself.

初始化新的回购协议时:
遍历ls -lR并选择其类型text, binary或忽略(即将其放入.gitignore)

When a new repo is init-ed:
Go through ls -lR and choose for it's type text, binary or ignore (ie put it in .gitignore)

调试:
使用 git-check-attr 检查属性匹配和计算是否符合要求

Debugging:
Use git-check-attr to check that attribute matching and computation are as desired

我们可能会将git视为松散地类似于USB驱动器的数据存储.

We may treat git as a data-store loosely analogous to how a USB drive is one.

如果说我们放入的东西相同，我们说驱动器正在工作.否则它已损坏.同样，如果我们提交的文件在结帐时相同出库，则存储库就可以了，否则(某物)会出现问题.关键问题是

We say the drive is working if the stuff we put in comes out the same. Else it's corrupted. Likewise if the file we commit comes out the same on checkout the repo is fine else (something) is borked. The key question is

这是不平凡的，因为我们在不同的上下文中隐式地应用了不同的相同"标准！

It's non-trivial because we implicitly apply different standards of "sameness" in different contexts!

• 二进制文件是字节序列
• 忠实地保留顺序就等于再现文件

...不同

• 文本文件由一系列可打印字符"组成-除了说 no cr no lf！
，我们不指定可打印字符概念
• 再次分隔(或终止)这些行的方式未指定
• 象征性地:
  类型Line = [Char]
  输入File = [Line]
• 未指定的第一天扩展会给我们提供ASCII，拉丁语，Unicode等...与此问题无关

• 第二个扩展是Windows * nix等的区别.JFTR 此类文件可能在年轻一代中鲜为人知，但也存在.记住行的顺序"概念可以在许多不同的级别上应用，这一点特别有用.

• A text file consists of a sequence of «printable characters» — let's leave the printable char notion unspecified other than to say no cr no lf!
• How these lines are separated (or terminated) is again unspecified
• Symbolically:
  type Line = [Char]
  type File = [Line]
• Expanding on the 1st unspecified gives us ASCII, Latins, Unicode etc etc... Not relevant to this question

• Expanding on the 2nd is what distinguishes windows *nix etc. JFTR this kind of file may be little known by the younger generation but also exists. And is particularly useful to remember that the notion "sequence of lines" can be imposed at many different levels.

我们不在乎相同性如何尊重未指定的部分

返回我们的

当我从Windows复制foo.txt到Linux时，我希望内容是不变的.但是，如果H:foo.txt 更改为 /media/name/Transcend/foo.txt，我感到非常满意.实际上，如果Windowsisms是通过未翻译的翻译过来的，反之亦然.

When I copy foo.txt from Windows to Linux I expect the contents to be invariant. However I'm quite satisfied if H:foo.txt changes to /media/name/Transcend/foo.txt. In fact it would be more than a bit annoying if the windowsisms came through untranslated or vice versa.

远销??? ¡¡再想一想！

IOW感谢Theodore T'这样的杰出人士，因此我们认为Linux可以读取Windows文件(系统)是理所当然的.发生这种情况是因为

IOW thanks to splendid folks like Theodore T'so we take it for granted that Linux can read a windows file (system). This happens because a non-trivial amt of

• 抽象匹配
• 抽象隐藏

发生在引擎盖下.

因此，我们希望签入git的文件与签出的文件相同 ...在不同的时间...以及操作系统！

We therefore expect that a file checked in to git is the same that's checked out... at a different time... And OS!

要注意的是，相同的概念非常重要，以至于git需要我们的帮助才能使我们的满意程度达到相同"……该帮助称为.gitattributes！

The catch is that the notion of same is sufficiently non-trivial that git needs some help from us in achieving that "sameness" to our satisfaction... That help is called .gitattributes!

这篇关于如何在跨平台兼容性的Git提交中强制一致的行尾的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！