『现学现忘』Git基础 — 20、Git中忽略文件补充
1、忽略文件常遇到的问题
有些时候,你想添加一个文件到Git,但发现添加不了,原因可能是这个文件被.gitignore
忽略了:
$ git add App.class
The following paths are ignored by one of your .gitignore files:
App.class
Use -f if you really want to add them.
如果你确实想添加该文件,可以用-f
参数强制添加到Git本地版本库:
关于-f
参数,描述如下:
-f, --force
:Allow adding otherwise ignored files.
允许添加被忽略的文件。
$ git add -f App.class
或者你发现,可能是.gitignore
写得有问题,需要找出来到底哪个规则写错了,可以用git check-ignore
命令检查:
$ git check-ignore -v App.class
.gitignore:3:*.class App.class
Git会告诉我们,.gitignore
的第3行规则忽略了该文件,于是我们就可以知道应该修订哪个规则。
还有些时候,当我们编写了规则排除了部分文件时:
# 排除所有.开头的隐藏文件:
.*
# 排除所有.class文件:
*.class
但是我们发现.*
这个规则把.gitignore
也排除了,并且App.class
需要被添加到版本库,但是被*.class
规则排除了。
虽然可以用git add -f
强制添加进去,但有强迫症的童鞋还是希望不要破坏.gitignore
规则,这个时候,可以添加两条例外规则:
# 排除所有.开头的隐藏文件:
.*
# 排除所有.class文件:
*.class
# 不排除.gitignore和App.class:
!.gitignore
!App.class
把指定文件排除在.gitignore
规则外的写法就是!
+文件名,所以,只需把例外文件添加进去即可。
小结
- 忽略某些文件时,需要编写
.gitignore
文件。 .gitignore
文件本身要放到版本库里,并且可以对.gitignore
做版本管理。- 可以不提交到本地版本库或远程仓库,只对本地副本有效。
- 可以提交到远程仓库,对所有
clone
下来的版本库生效。(所以个人特殊忽略不要在这里添加)
2、忽略文件配置优先级
Git检查忽略规则的时候有多个来源,它的优先级如下(由高到低):
- 从命令行中读取可用的忽略规则。
- 当前目录定义的规则(
.gitingore
文件)。 - 父级目录定义的规则,依次递推,目录结构较高的
.gitignore
文件将被较近的.gitignore
文件中相同的配置所覆盖(.gitingore
文件)。 .git/info/exclude
文件中定义的规则。core.excludesfile
中定义的全局规则。
3、忽略已跟踪文件的改动(本机使用)
(1)需求说明
之前的忽略方案,都是适用于未跟踪文件的忽略,而对于已跟踪(track
)文件的改动并不适用,好在针对这种情况,Git也提供了我们方法去忽略。
换句话说,就是添加忽略之后,修改已经提交到版本库中的文件是无法忽略的。
即:
.gitignore
只能忽略那些原来没有被track
的文件,如果某些文件已经被纳入了版本管理中,则修改.gitignore
是无效的。
(2)处理步骤
自己思考的方式:(稀烂哈哈)
- 将项目
clone
到本地。 - 删除项目中的忽略配置,如:根目录中的
.gitignore
文件。 - 然后在创建新的
.gitignore
文件,重新配置忽略。
正确的做法:
clone
下来的仓库中手动设置,不要检查特定文件的更改情况。
执行命令如下:
这样已经在本地版本库中的文件修改之后,也可以被忽略。# 忽略跟踪(提交代码时,忽略某一个文件不提交,即某个文件不被版本控制) # file-path是目标文件路径 git update-index --assume-unchanged file-path # 恢复跟踪 git update-index --no-assume-unchanged file-path
不过如果执行git checkout
(切换分支)和git reset
(回退版本)命令的时候仍然会影响到这些文件,并把内容恢复到被跟踪的内容(再次执行上面命令,修改仍然不会被跟踪)。- 另一种方式:
Git还提供了另一种exclude
的方式来做同样的事情,就是之前说过的在本地版本库中的.git/info/exclude
文件中配置忽略,这里设置的忽略规则是你自己本地需要排除的文件, 他不会影响到其他人,也不会提交到版本库中去。
4、autocrlf和safecrlf参数说明
(1)提出问题
我们在配置全局忽略.gitconfig
文件的时候,可能会看到如下配置:
[core]
autocrlf = true
safecrlf = false
excludesfile = C:/Users/L/gitignore_global.txt
那么autocrlf = true
和safecrlf = false
是什么意思?
LF
是Linux系统下的换行符,而CRLF
是Windows系统下的换行符。由于我们的文件创建于Linux系统下(Git Bash中创建),而保存中Windows系统中,所以文件中的行结束符,要使用Windows下的CRLF
格式换行,而在Git中的默认配置是自动转换。
因为在Git的忽略文件中,是一行一行的忽略规则,而autocrlf
和safecrlf
就是对转变换行格式的具体配置。
(2)autocrlf说明
autocrlf = true
:表示要求Git在提交时将CRLF
转换为LF
,而在检出时将LF
转换为CRLF
。autocrlf = false
:在提交与检出代码的时候均不对换行符进行转换。autocrlf = input
:表示在提交时将CRLF
转换为LF
,而检出时不转换。
以上可手动配置在.gitconfig
文件中,
使用命令行配置如下:
# 提交时转换为LF,检出时转换为CRLF
git config --global core.autocrlf true
# 提交时转换为LF,检出时不转换
git config --global core.autocrlf input
# 提交检出均不转换换行格式
git config --global core.autocrlf false
提示:当
git add
遇到fatal: LF would be replaced by CRLF
或者fatal: CRLF would be replaced by LF
的错误时,我们就需要考虑autocrlf
参数的配置了。
建议:
Windows:(true)
提交时,将
CRLF
转成LF
再提交。切出时,自动将
LF
转为CRLF
。MAC/Linux: (input)
提交时, 将
CRLF
转成LF
再提交。切出时,保持
LF
即可。
这样即可保证仓库中永远都是LF
, 而且在Windows工作空间都是CRLF
,在Mac/Linux工作空间都是LF
。
(3)safecrlf说明
autocrlf = ture
:拒绝提交包含混合换行符的文件。autocrlf = false
:允许提交包含混合换行符的文件。autocrlf = warn
:提交包含混合换行符的文件时给出警告。
以上可手动配置在.gitconfig
文件中,
使用命令行配置如下:
# 拒绝提交包含混合换行符的文件
git config --global core.safecrlf true
# 允许提交包含混合换行符的文件
git config --global core.safecrlf false
# 提交包含混合换行符的文件时给出警告
git config --global core.safecrlf warn
参考: