gitattributes(5) Manual Page
1.gitattributes是什么？
gitattributes用于定义每个路径的属性。
其语法是：pattern attr1 attr2 ...
2.什么叫做定义每个路径的属性？
比如:（pattern attr1） *.txt text
*.txt就是一个pattern，用来匹配所有的.txt文件，匹配到的各个文件就有各自的路径。
比如text属性，text就是一个属性名，它的值是true。
3.pattern后面可以接多个属性，又是怎么给属性赋值的呢？
每种属性可能有Set，Unset，Set to a value，Unspecified几种状态。
Set状态就是 其值是true，单独写出这个属性名就表示其值是true。
Unset状态就是 其值是false，属性名加上-就表示其值是false。
Set to a value状态就是 属性名=值，值就是一个字符串
Unspecified状态 就是pattern没有匹配到路径，以及没有说明路径有还是没有属性。
举个例子，text属性
Set状态 text
Unset状态 -text
Set to a value状态 text=auto
4.在哪些地方可以写gitattributes呢？
①. $GIT_DIR/info/attributes 文件中 （优先级高）
②. 各个文件路径所在目录下的.gitattributes文件，以及所有父目录下的.gitattributes文件（优先级中，距离越远优先级越低）
③. 全局及系统范围下的文件（优先级低）
5.各个位置的gitattributes分别用于什么目的呢？
如果只想影响一个用户的某一个repository，就放在$GIT_DIR/info/attributes中。因为这个文件是repository所独有的，是不会放到版本控制中的，因而别的repository访问不到。
对于所有用户都感兴趣的gitattributes就放到.gitattributes文件中。因为这些文件会放到版本控制中，分发给其他的repository。
对于影响一个用户的所有repository的属性就放到由core.attributesfile配置选项指定的文件中。
针对一个系统中的所有用户的属性应该放到$(prefix)/etc/gitattributes文件中。
6.gitattributes中的属性对Git有什么影响呢？
对于迁入或迁出的影响：
迁入就是将working tree中你准备的内容保存到repository中，比如git add，git commit命令。
迁出就是将保存在repository中的内容拷贝到working tree中，比如git checkout，git merge命令。
text属性
给一个路径设置text属性可以启用和控制end-of-line的规范化。当一个文本文件被规范化时，在repository中它的行结束符会被转换为LF。
要控制在working directory中使用的行结束符，就要为单个文件使用eol属性以及为所有文本文件使用core.eol配置。
①.Set状态 在路径中设置text属性为Set状态会启用end-of-line的规范化并将这个路径标记为文本文件。不需要猜测内容类型，End-of-line转换就会发生。
②.Unset状态 在路径中设置text属性为Unset状态就是告诉git在迁入迁出时不尝试任何的end-of-line转换。
③.Set to string value "auto" 状态 设置text属性为“auto”状态时， 路径就标记为自动end-of-line规范化。如果git确定内容是文本，在迁入时，行结束符就被规范化为LF。
④.Unspecified状态 如果text属性没有被指定，git使用core.autocrlf配置变量来决定这个文件是否应该被转换。
任何其他值都会使得git的行为和text属性设置为Unspecified状态时一样。
eol属性
这个属性用于设定在working directory中使用的行结束符。它会动用end-of-line规范化而不做任何的内容检查，高效地设置text属性。
①.Set to string value "crlf" 状态 这个设置会强制git在迁入文件时规范化行结束符，并且当文件迁出时，将它们转为CRLF。
②.Set to string value "lf" 状态 这个设置会强制git在迁入文件时规范化行结束符为LF，并且当文件迁出时，阻止转换为CRLF。
crlf属性的向后兼容性
为了向后兼容，crlf属性按如下方式解读：
crlf text -crlf -text crlf=input eol=lf
End-of-line转换
虽然git通常只保留文件内容，但是它可以被配置来规范化在repository中的行结束符为LF，可以选择在文件迁出时将它们转换为CRLF。
这是一个让git规范化.txt，.vcproj，.sh文件的例子，确保在working directory中，.vcproj文件有CRLF，.sh文件有LF，并且不管.jpg文件的内容阻止其被规范化。
*.txt text *.vcproj eol=crlf *.sh eol=lf *.jpg -text
其他的源代码管理系统规范化在repository中的所有文本文件，并且在git中有两种启用类似的自动规范化的方式。
如果你只是想在你的working directory中用CRLF行结束符而不管你的repository，你可以设置config变量“core.autocrlf”而不用改变任何属性。
[core]
autocrlf = true
这不会强制所有文本文件的规范化，但是确实会保证你引入到repository中的文本文件的行结束符，在被加入时规范化为LF，确保在repository中已经规范化的文件保持规范化。
如果你想和强制end-of-line规范化的源代码管理系统进行互操作，或你只是想要在你的repository中的所有文本文件被规范化，你应当为所有文件设置text属性为“auto”。
* text=auto
这会保证所有git认为是文本的文件在repository中规范化（LF）。core.eol配置变量控制在你的working directory中git会使用的行结束符；默认是使用你的平台的本地行结束符。如果core.autocrlf设置了就是CRLF。
注意
当在一个既存的repository中启用text=auto时，任何包含CRLFs的文本文件应当被规范化。如果它们没有被规范化的话，在下一次某个人变更了它们的话，会造成不幸的错误认定。
从一个干净的工作目录开始：
$ echo "* text=auto" >>.gitattributes $ rm .git/index # Remove the index to force git to $ git reset # re-scan the working directory $ git status # Show files that will be normalized $ git add -u $ git add .gitattributes $ git commit -m "Introduce end-of-line normalization"
对于任何不应该被规范化的文件出现在git status中的话，在运行git add -u之前设置text属性为unset状态。
manual.pdf -text
相反，git未检测到的文本文件可以手动启用规范化。
weirdchars.txt text
如果core.safecrlf被设为“true”或“warn”，git会验证这个转换对于当前的core.autocrlf设置是否是可逆的。对于“true”，git拒绝不可逆转的转换。对于“warn”，git只是打印一个警告，但接受不可逆的转换。
安全触发器阻止对work tree中的文件执行这种转换，但有一些例外。 即使…
・ git add・・・
・ git apply・・・
・ git diff ・・・