当前位置: 首页
编程语言
Git忽略文件配置教程详解gitignore使用方法

Git忽略文件配置教程详解gitignore使用方法

热心网友 时间:2026-05-07
转载

Git忽略文件.gitignore

咱们搞开发的时候,都懂一个道理:不是项目里的每一个文件都得扔进版本库。比如编译生成的“target”目录,或者各种临时文件、日志,要是都提交上去,那仓库可就臃肿得没法看了。这事儿怎么解决呢?很简单,在Git工作区的根目录下,创建一个名叫“.gitignore”的特殊文件。把那些你想让Git“视而不见”的文件或目录名称填进去,Git在后续操作中就会自动忽略它们。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新! 👉 点此立即查看 👈

gitignore的基础用法

# .gitignore配置文件的一些通用技巧 [参考:https://git-scm.com/docs/gitignore]

# 1.空白行不匹配任何文件,所以可以作为可读性的分隔符,同时两端的空格将会被忽略。

# 2.使用[#]开头,将会注释掉整行,使其不进行匹配操作。如果需要匹配#开头,可以使用转义字符[\]。

# 3.1匹配模式以[/]结尾,表示想要匹配一个目录及其子文件。(比如[foo/]会匹配foo目录及其下面的路径。)

# 3.2匹配模式不包含[/],将会全局匹配该文件。

# 4.通配符

# [*]: 匹配除[/]以外的任何内容,也就意味着[*]不能跨目录。

# [?]: 匹配除[/]和[[]以及[]]以外的任何一个字符。

# [**]:匹配所有的内容,或者说匹配任意目录下的内容。

# 示例:

# 1.[**/foo/bar] 将会匹配所有直接在foo目录下的bar,无论foo处在何处。

# 2.[foo/**]则表示匹配foo目录下的所有文件和目录。

# 3.[a/**/b]则可以匹配a/b, a/c/b, a/c/d/b,即此处的[**]可以表示0个或多个。

# !!! 需要注意的是,除上面示例的用法外,剩余的[**]都是无效的。

# 5.可以通过前缀[!]来表示不忽略某些文件。比如可以通过[!a]来确保文件a不会被忽略,即使前面已经声明了忽略其父目录。该模式优先级高于普通忽略模式。

Git 三种方法忽略提交的文件

在Git项目中定义 .gitignore 文件

这是最主流、最推荐的方式。操作起来也很直观:在项目的某个目录(通常是根目录)下创建一个“.gitignore”文件,然后在里面写上你的忽略规则。这样一来,这个目录下的文件提交行为就都由这个文件来管理了。

关键是,这个“.gitignore”文件本身是可以提交到仓库里的。这就意味着,项目组里的所有小伙伴都能共享同一套精心定义好的“清洁”规则,从源头上保持仓库的整洁。

文件里的语法是每行一条规则。来看几个简单的例子:

*.log
*.temp
/vendor/

在Git项目的设置中指定排除文件

有时候,你可能有些个人偏好或临时产生的文件不想提交,但又不想把这些规则共享给整个团队。这时候,可以试试这个方法。

操作路径是:编辑你本地项目下的“.git/info/exclude”文件,把要忽略的文件路径加进去。需要注意,这里写的路径,其根目录就是项目的根目录。

这个方法的好处是,规则只对你自己的本地仓库生效,不会影响其他协作者。算是一种“私人订制”的忽略列表。

定义Git全局的 .gitignore 文件

如果你发现自己经常在不同的项目里重复添加某些忽略规则(比如你自己常用的编辑器临时文件),那么设置一个全局忽略文件会方便很多。

这属于Git应用级别的配置,跟具体项目无关。你需要先在一个固定的位置(比如用户主目录)创建一个“.gitignore”文件,然后把那些通用的规则放进去。最后,用下面这条命令告诉Git它的位置:

git config --global core.excludesfile ~/.gitignore

配置好之后,你所有的Git项目都会自动应用这些全局忽略规则,省去了在每个项目里重复配置的麻烦。

.gitignore文件中的忽略规则

规则看似简单,但细节不少,理解透了才能用得精准:

空格本身不匹配任何文件,通常用作格式上的分隔符以提高可读性。如果需要匹配空格,得用反斜杠转义。

# 开头:这一行会被当作注释,Git直接跳过。当然,真要匹配以#开头的文件,也得靠反斜杠转义。

! 开头:表示“否定”或“例外”。意思是,即使前面有规则忽略了这类文件,加了“!”的这条规则也能把它重新包含进来。不过要注意,如果它的父目录被忽略了,光用“!”可能也救不回来。

/ 结尾:这只匹配目录。写上“doc/”,就意味着忽略名为“doc”的文件夹及其里面的所有东西,但不会忽略一个叫“doc”的普通文件。

/ 开头:匹配规则会从项目根目录开始生效。比如“/README.md”就只忽略根目录下的README.md文件。

不包含斜杠的模式:它会相对于当前.gitignore文件所在的目录进行匹配。如果这个模式是写在项目根目录的.gitignore里,那就相当于相对于项目根目录。

使用 **:这是“超级通配符”,可以匹配任意层级的目录。可以用在模式的开头、中间或结尾,非常灵活。比如“**/tmp”就能匹配任何位置的“tmp”文件或目录。

使用 ?:通用匹配任意单个字符。

使用 []:匹配方括号内列出的任意单个字符。

常用匹配示例:

bin/:           忽略当前路径下的bin文件夹,该文件夹下的所有内容都会被忽略,不忽略 bin 文件
/bin:           忽略根目录下的bin文件
/*.c:           忽略根目录下的 cat.c,不忽略 build/cat.c
debug/*.obj:    忽略 debug/io.obj,不忽略 debug/common/io.obj 和 tools/debug/io.obj
**/foo:         忽略 /foo, a/foo, a/b/foo 等
a/**/b:         忽略 a/b, a/x/b, a/x/y/b 等
!/bin/run.sh:   不忽略 bin 目录下的 run.sh 文件
*.log:          忽略所有 .log 文件
config.php:     忽略当前路径的 config.php 文件

ja va忽略文件

# 编译后的class文件,忽略所有以[.class]结尾的文件
*.class

# 日志文件,忽略所有以[.log]结尾的文件
.*.log

# BlueJ 文件,忽略所有以[.ctxt]结尾的文件
*.ctxt

# Mobile Tools for Ja va (J2ME),忽略[.mtj.tmp/]目录及其子文件
.mtj.tmp/

# 打包文件,忽略所有以[.jar]或[.war]或[.nar]或[.ear]或[.zip]或[.tar.gz]或[rar]结尾的文件
*.jar
*.war
*.nar
*.ear
*.zip
*.tar.gz
*.rar

IDE环境忽略文件

.idea/
*.idea/compiler.xml
.idea/encodings.xml
.idea/modules.xml
*.iml

ma ven忽略文件

target/
pom.xml.tag
pom.xml.releaseBackup
pom.xml.versionsBackup
pom.xml.next
release.properties
dependency-reduced-pom.xml
buildNumber.properties
.mvn/timing.properties
# 避免忽略 Ma ven wrapper jar 文件(通常.jar文件是被忽略的)
!/.mvn/wrapper/ma ven-wrapper.jar

other环境忽略文件

*.sw?
.#*
*~
.classpath
.project
.settings/
bin
build
target
dependency-reduced-pom.xml
*.sublime-*
/scratch
.gradle
Guardfile
README.html
*.iml
.idea

.gitignore规则不生效

这是很多开发者都会踩的一个坑:为什么我明明加了规则,Git还在跟踪那个文件?

问题的关键在于,.gitignore只对尚未被Git跟踪(untracked)的文件起作用。如果某个文件已经被提交过(即已纳入版本管理),那么你再修改.gitignore来忽略它,是无效的。Git已经“认识”它了。

解决办法其实也不难,核心思路是:让这个文件先从Git的跟踪列表里“脱钩”。具体操作分三步走:

git rm -r --cached .
git add .
git commit -m 'update .gitignore'

简单解释一下:第一条命令“git rm -r --cached .”会删除所有已跟踪文件在暂存区(索引)中的记录,但保留工作区的实际文件。然后再重新“git add .”,这时.gitignore规则就会生效,那些被忽略的文件就不会再被添加进去了。最后提交更改即可。

需要警惕的是,这个操作会影响所有文件,如果是团队协作的项目,最好提前沟通。对于单个文件的处理,可以把“.”换成具体的文件路径。

来源:https://www.jb51.net/program/336202ngh.htm

游乐网为非赢利性网站,所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系youleyoucom@outlook.com。

同类文章
更多
Ubuntu系统下使用Go语言实现机器学习的实践指南

Ubuntu系统下使用Go语言实现机器学习的实践指南

在Ubuntu上使用Go进行机器学习需先安装环境并配置工作空间,通过goget获取golearn等库。编写代码遵循数据加载、模型训练、预测评估的流程后运行程序。Go在性能与并发方面有优势,但生态不如Python丰富,更适合特定工程场景或统一技术栈的团队探索。

时间:2026-05-07 13:59
Ubuntu系统下Go语言程序打包方法与核心要点

Ubuntu系统下Go语言程序打包方法与核心要点

在Ubuntu中打包Go应用需关注环境配置、交叉编译与优化。通过GoModules管理依赖,使用CGO_ENABLED=0生成静态二进制文件以实现跨平台兼容。利用UPX和链接器参数减小体积,采用Docker多阶段构建制作最小镜像。交付时建议包含平台信息并签名,注意解决动态库依赖和版本锁定等常见问题。

时间:2026-05-07 13:58
Android开发中高效管理多个CheckBox组件的实用技巧

Android开发中高效管理多个CheckBox组件的实用技巧

在Android应用开发过程中,高效管理多个功能相似的复选框(CheckBox)是提升开发效率的关键。无论是应用设置界面、多选列表,还是动态生成的选项列表,如果对每个CheckBox都进行单独引用和操作,代码会迅速变得冗长且难以维护。那么,是否存在更优雅的解决方案?答案是肯定的——通过数组或动态集合

时间:2026-05-07 13:58
面向对象编程中封装字段如何提升代码安全性与维护性

面向对象编程中封装字段如何提升代码安全性与维护性

将类的公共字段改为私有,并提供公共的获取和设置方法,是提升代码安全性与可控性的基础重构。此举能防止外部随意读写,避免状态失控,并便于后续加入校验、脱敏等控制逻辑,适用于核心业务或敏感字段。

时间:2026-05-07 13:58
Master-Worker架构解析如何实现并发任务的负载均衡与结果高效合并

Master-Worker架构解析如何实现并发任务的负载均衡与结果高效合并

Master-Worker架构的核心在于实现任务划分、动态负载均衡与可靠结果合并的协同:任务必须具备无依赖性与可聚合性,负载需依据节点实时能力进行动态分配,结果合并则需通过唯一ID、版本号及超时重试机制确保不丢失、保顺序、容故障。 构建一个高性能的Master-Worker并发架构,核心在于系统性地

时间:2026-05-07 13:58
热门专题
更多
刀塔传奇破解版无限钻石下载大全 刀塔传奇破解版无限钻石下载大全
洛克王国正式正版手游下载安装大全 洛克王国正式正版手游下载安装大全
思美人手游下载专区 思美人手游下载专区
好玩的阿拉德之怒游戏下载合集 好玩的阿拉德之怒游戏下载合集
不思议迷宫手游下载合集 不思议迷宫手游下载合集
百宝袋汉化组游戏最新合集 百宝袋汉化组游戏最新合集
jsk游戏合集30款游戏大全 jsk游戏合集30款游戏大全
宾果消消消原版下载大全 宾果消消消原版下载大全
  • 日榜
  • 周榜
  • 月榜
热门教程
更多
  • 游戏攻略
  • 安卓教程
  • 苹果教程
  • 电脑教程