当前位置:   article > 正文

gitattributes手册

.gitattributes

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 ・・・

 

转载于:https://www.cnblogs.com/niaomingjian/p/8446819.html

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/Monodyee/article/detail/693913
推荐阅读
相关标签
  

闽ICP备14008679号