Git处理行结束符

Dealing with line endings (Windows)

如果你正在使用Git在GitHub上和别人协作的话，确保Git处理行结束符的配置已经正确配置了。

每次在键盘上按下return键时，实际上你正在插入一个称之为行结束符（line ending）的不可见字符。由于历史的原因，不同的操作系统处理行结束符的方式的不一样的。

当你查看一个文件的变更时，Git会以它自己的方式处理行结束符。因为你在项目中使用Git和GitHub进行协作，Git可能产生预料外的结果。比如你在Windows系统上工作，而你的协作者是在OS X上做的变更。

针对行结束符的全局设定

git config core.autocrlf命令被用来改变Git处理行结束符的方式。它接受一个单一的参数。

在Windows中，简单地传递true给这个配置。比如：

$ git config --global core.autocrlf true

# Configure Git on Windows to properly handle line endings

每个库的设定

你可以选择通过配置一个特殊的.gitattributes文件在每个库的基础上配置Git管理行结束符的方式。这个文件被提交给库并且覆盖一个各自的core.autocrlf设置，确保所有用户行为的一致性，而不管他们的Git设置。.gitattributes文件的优势是你的配置和你的库相关。你不需要担心你的协作者是否和你有相同的配置。

.gitattributes文件必须在库的根目录创建并像其他文件一下提交。

.gitattributes文件就像包含两列的表：

左边是给Git去匹配的文件名。

右边是Git将会用于文件的行结束符配置。

.gitattributes 文件例子，使用它作为你的库的模板：

# Set the default behavior, in case people don't have core.autocrlf set.

* text=auto

# Explicitly declare text files you want to always be normalized and converted

# to native line endings on checkout.

*.c text

*.h text

# Declare files that will always have CRLF line endings on checkout.

*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.

*.png binary

*.jpg binary

你注意到文件被 *c，*.sln，*.png匹配，一个空格分割，然后是设置，text，text eof=crlf，binary。

下面是一些可能的设置：

text=auto Git以它认为最好的方式处理文件。这是个好的默认选项。

text eof=crlf 在checkout时，Git总是将文件结束符转换为CRLF。对于必须保留CRLF结尾的文件，即便是在Linux或OS X中，你也应该使用它。

text eof=lf 在checkout时，Git总是将文件结束符转换为LF。对于必须保留LF结尾的文件，即便是在Windows中，你也应该使用它。

binary Git会理解指定的文件不是文本，它就不会尝试去改变它们。这个设定是-text -diff 的别名。

在变更行结束符设置后刷新库

在你设定core.autocrlf配置，提交.gitattributes文件之后，你可能发现Git想去提交你未变更的文件。此时，Git是想为你改变每个文件的行结束符。

自动配置你的库的行结束符的最好方法是首先用Git备份你的文件，删除你的库（除了.git目录），然后立即恢复所有文件。

1.在Git中保存当前的文件，那么你的工作就不会丢失。

$ git add . -u

$ git commit -m "Saving files before refreshing line endings"

2.删除index，强制Git再扫描工作目录。

$ rm .git/index

3.重写Git的index，获取新的行结束符。

$ git reset

4.显示重写后的规范化文件。

$ git status

5.将你变更的文件复原，准备提交。可以用这个机会检查哪些文件没有被改变。

$ git add -u

# It is perfectly safe to see a lot of messages here that read

# "warning: CRLF will be replaced by LF in file."

6.重写.gitattributes 文件。

$ git add .gitattributes

7.将你的改变提交到库中。

$ git commit -m "Normalize all the line endings"

测试

1.在Windows中创建一个文本文件file1.txt，提交，push

2.在Linux中git clone，看到文件行结束符是CRLF

3.添加.gitattributes文件，设置Git以它认为适当的方式处理行结束符。直接commit，push

4.在Linux中git clone，看到文件行结束符依然是CRLF

5.按照【在变更行结束符设置后刷新库】设置后，在Linux中git clone，看到文件行结束符变为LF

6.强制.txt设置为LF

7.按照【在变更行结束符设置后刷新库】设置后以及在Windows中创建一个文本文件file2.txt，提交，push

8.工作目录中的file1.txt，file2.txt还是CRLF，但是在Windows另一个文件夹中git clone，它们的行结束符变为LF。

似乎在checkout时，文件的行结束符可以保证和配置中一致，但是原来的工作目录中似乎并没有改变。

巴特西

Git处理行结束符

Dealing with line endings (Windows)

针对行结束符的全局设定

每个库的设定

在变更行结束符设置后刷新库

测试

最新文章

热门文章

巴特西

Git处理 行结束符

Dealing with line endings (Windows)

针对行结束符的全局设定

每个库的设定

在变更行结束符设置后刷新库

测试

最新文章

热门文章

Git处理行结束符