1. 从下载到IDEA识别Git环境准备链路上的细节坑先把话说在前面网上搜“IDEA整合Git”百分之八十的教程默认你的电脑上已经装好了Git然后直接打开IDEA开始配置。但以我这些年帮同事排查问题的经验来看很多“配置不成功”的案例源头其实在更早的位置——Git本身没装对或者装了但IDEA压根没认出来。所以第一步我们把这条链路完整捋一遍确保地基没问题。1.1 Git安装时最容易忽略的两个选择项Git的Windows安装包是个exe一路Next似乎谁都会但有两个选项会直接影响IDEA的集成体验。第一个是安装路径。官方默认路径通常是C:\Program Files\Git这个路径中间带空格理论上没问题但个别Windows环境下的脚本解析空格时容易出幺蛾子。如果你是新手建议直接装到不带空格的路径比如D:\Git或者C:\Git。你可能会觉得我在小题大做但等到后面配置Gitee密钥或者写自动化脚本时路径问题真的会跳出来咬你一口。第二个是安装过程中遇到Adjusting your PATH environment这一步务必选第二项或第三项Git from the command line and also from 3rd-party software而不是第一项Use Git from Git Bash only。选第一项的话Git命令只能在Git Bash里用Windows的CMD和IDEA的终端都调用不到git命令后续会非常难受。安装完成后打开CMD或者PowerShell输入git --version如果能正常输出版本号说明这一步走通了。我见过不少同事装完Git从来不验证直接去IDEA里配置结果IDEA提示找不到Git可执行文件回头才发现在PATH那一环就选错了。1.2 IDEA中配置Git的准确操作路径IDEA检测Git并不需要重启它是动态感知的。打开IDEA依次进入File - Settings - Version Control - Git在右侧的Path to Git executable这一栏IDEA通常会自己探测到Git的安装路径。如果这一栏是空的或者提示Invalid path点击旁边的...按钮手动选择Windows下一般是C:\Program Files\Git\bin\git.exe或你自定义路径下的git.exemacOS下一般是/usr/local/bin/git或/opt/homebrew/bin/git取决于你用什么方式安装的选完之后点右下角的Test按钮。如果IDEA弹出Git executed successfully说明IDEA已经正确识别到Git。这里我想多说一句Git路径必须精确到git.exe这个文件不是Git安装根目录也不是bin目录。曾经有位同事把路径填成了D:\GitIDEA倒是不报错但所有Git操作都失效这就是路径层级没搞对。1.3 Windows下最隐蔽的坑凭据管理器与换行符安装和识别都搞定了但在实际提交代码前Windows用户还有两个默认行为要调整否则后面迟早要踩坑。第一个是凭据管理器。Git默认会启动Git Credential Manager帮你记住Gitee或GitHub的账号密码。这本来是方便但麻烦在于如果你切换了账号或者密码改了凭据管理器会一直用旧凭据去认证导致你反复提交失败而IDEA又只会报一个笼统的Authentication failed。真遇到这个情况去Windows的“凭据管理器”里把旧凭据删掉重新认证一次就好。第二个是换行符转换。Windows的换行符是CRLFLinux和macOS是LF。Git默认在提交时会自动把CRLF转换成LFcore.autocrlftrue在检出时再把LF转回CRLF。理论上这能避免跨平台换行符问题但在一些老项目里策略配置不当会导致整个文件显示为已修改而git diff又看不出任何差异。个人习惯是把它设置成git config --global core.autocrlf input意思是不管在什么平台提交到仓库时统一转成LF检出时不做转换。这样写代码的人不会因为换行符被反复折磨。2. 先用起来IDEA中Git的日常提交工作流环境通了之后核心操作就集中在几个高频动作上。先别急着上手我们花两分钟把IDEA里Git的几个按钮和概念对着图认一遍不然你会不知道什么时候该用哪个功能。2.1 初始化仓库与第一次提交如果你手头是一个新项目还没有任何Git关联操作窗口在IDEA的顶部菜单VCS - Enable Version Control Integration弹出菜单选择Git然后点OK。这一步做完IDEA的右上角会出现通常说的Git工具栏——一个绿色的对勾Commit、一个蓝色的向下箭头Update、一个向上的箭头Push以及分支名下拉框。但这里有个新手非常容易犯的错Enable Version Control Integration之后项目里的文件并不会立即显示为Git管理的状态你需要先做一次Commit才能让所有文件进入Git的追踪视野。在IDEA里首次提交的路径是右键项目根目录 - Git - Commit Directory...接着IDEA会弹出一个Commit窗口这里会列出所有变更文件、改动内容diff、以及下方的Commit Message输入框。第一次提交Message一般写Initial commit就行。点Commit按钮右下角出现Committed successfully这个项目才真正完成了Git的初始化。需要注意一个细节Commit窗口下方有一个Commit按钮旁边的下拉小箭头展开后能看到Commit and Push...。第一次提交不用选这个因为此时远端仓库还没配置Push会失败。先本地提交后面关联远端再Push。2.2 关联远程仓库并完成首次推送关联远程仓库本质有两种操作顺序不同的人习惯不同效果一致一种是先在Gitee或GitHub上建一个空仓库拿到仓库地址在IDEA里执行Git - Manage Remotes添加origin地址然后执行Push。另一种是从远端仓库拉下来再填代码也就是Git - Clone...输入仓库地址直接克隆。第二种方式更适合加入已有项目我们重点说第一种。在Gitee上新建仓库时它会给出一串地址比如https://gitee.com/yourname/yourproject.git拿到地址后IDEA操作路径Git - Manage Remotes... - 点击 号 - Name填originURL填上面的地址 - OK然后执行推送点工具栏上的向上箭头或者快捷键CtrlShiftKIDEA会让你选择要推送的分支确认后开始Push。首次Push时IDEA会弹出窗口要求你输入Gitee/GitHub的账号密码或者跳转浏览器完成OAuth认证。验证通过后代码就推上去了。之后你打开Gitee仓库页面能看到IDEA生成的.gitignore文件了吗大概率看不到。因为IDEA默认不会帮你生成这个文件除非你用的是Spring Initializr这类脚手架创建的项目。这就引出了本文的核心问题忽略文件到底该怎么配。2.3 IDEA里“变色”的文件到底代表什么状态细节操作之前先把文件颜色的逻辑说清楚因为这个搞不懂你会觉得Git的状态提示完全不可理喻。IDEA的Project面板中不同颜色的文件代表不同的Git状态红色未加入版本控制也就是Untracked文件。新创建的文件默认都是这个状态。绿色已加入版本控制但尚未提交的新文件。蓝色已加入版本控制且本地修改过但没有提交。灰色被忽略的文件通常是.gitignore配置之后出现的效果。白色/普通已提交且工作区干净。这个颜色体系一旦建立起来你扫一眼整个项目面板就知道哪些文件动了、哪些文件是新的、哪些文件不用管。而忽略文件的作用恰恰就是让我第一眼扫过去时不会被target目录下几百个编译产物干扰。3. 重头戏忽略文件配置的三种思路和.gitignore语法精讲现在说到正题了。IDEA里配置Git忽略文件其实不止一种方式不同方式适用的场景和持久化程度完全不同。如果你在网上搜过会发现答案五花八门——有人让你装插件有人让你改IDEA设置还有人让你在项目根目录建文件。这些都对但背后的逻辑和适用边界不一样。我按实际开发中的使用频率和重要程度从最常用的开始讲。3.1 为什么必须忽略这些文件一个真实的仓库崩溃案例先讲一个我实际遇到过的案例。有个同事负责的项目代码量不算大但有一天代码托管平台提示仓库体积超过500MB。我们查了一圈发现问题出在target/目录里的编译产物被反复提交、反复变更Git仓库的.git目录膨胀到一个离谱的体积。更麻烦的是每次IDE编译完target/下面大量文件的修改时间变化会让Git以为文件有改动整个项目面板一片蓝色看起来像改了几百个文件实际上代码一行没动。这个案例说明一个道理忽略文件的本质不是“减少麻烦”而是保护仓库的纯净度。仓库里应该只有源码、配置文件和文档编译产物、IDE配置、系统文件这些都不应该进来。常见的需要忽略的文件分几类编译产物Java项目里的target/、out/目录前端项目里的node_modules/、dist/、build/目录。IDE本地配置IDEA产生的.idea/目录、*.iml文件Eclipse产生的.classpath、.project、.settings/目录。这些是个人开发环境差异不应该提交到仓库。有一个例外如果你用了类似EditorConfig之类的团队统一配置需要提交的部分要单独保留。系统文件.DS_StoremacOS、Thumbs.dbWindows。日志和临时文件*.log、*.tmp、*.cache。环境相关配置.env环境变量、application-local.yml本地私有配置等这些往往包含数据库密码等敏感信息绝不能进仓库。3.2 方式一在项目根目录创建 .gitignore 文件最推荐随仓库分发这是最标准、最推荐的做法。在项目根目录创建一个名为.gitignore的文件把要忽略的目录或文件按照语法规则写进去提交到仓库全队共享一份规则。IDEA创建这个文件有两种路径。一种是在项目根目录右键 -New - File输入文件名.gitignore注意IDEA可能会提示你安装.gitignore插件不装也能写文件装了有语法高亮和自动补全体验更好。另一种是使用IDEA自带的模板生成功能右键项目根目录 -New - .ignore file - .gitignoreIDEA会弹出一个模板选择窗口支持从几百种模板里勾选然后自动生成配置文件。以Java项目为例一份典型的.gitignore长这样# Compiled class file *.class # Log file *.log # BlueJ files *.ctxt # Mobile Tools for Java (J2ME) .mtj.tmp/ # Package Files # *.jar *.war *.nar *.ear *.zip *.tar.gz *.rar # virtual machine crash logs hs_err_pid* # Maven target/ # IDEA .idea/ *.iml # Eclipse .classpath .project .settings/ bin/ # OS .DS_Store Thumbs.db # Env .env application-local.yml写完保存后IDEA里面对应文件会变成灰色也就是已忽略状态。这个文件本身要提交到Git仓库里这样团队其他人拉下代码后也会自动应用同一套忽略规则。需要额外说明的是target/可以加也可以选择不加库文件的正则。从惯例来说target/是Maven项目的标准输出目录Java项目几乎人人都在忽略行里写它。而*.jar和*.war这种要看你项目的依赖管理方式如果你用的是Maven或Gradle依赖包不需要提交那就忽略如果你维护的是传统Web项目是手动拷jar包到WEB-INF/lib下的那就千万不能忽略否则别人拉下代码跑不起来。3.3 方式二IDEA设置里配置全局忽略解决“自己的文件不想让IDEA扫描”的问题.gitignore的规则是随项目走的但它有一个覆盖不到的场景你不想让某个文件进入仓库但又不想把这个规则提交到项目.gitignore里去影响团队其他人。比如你自己本地的application-dev.yml数据库地址团队其他人用的是另一套配置。这时候可以用IDEA自己的忽略机制。路径是File - Settings - Editor - File Types在右侧Recognized File Types列表中选中Ignore files and folders然后在下面的输入框中追加你要忽略的文件名或目录名用英文分号分隔。比如追加application-dev.yml;这里有个坑IDEA的这项设置是纯IDE层面的忽略只是让IDEA不再追踪和显示这些文件不会影响Git的行为。也就是说如果Git之前已经跟踪了application-dev.ymlIDEA忽略它并不等于Git忽略它推送时它还是会被推上去。真正的全局忽略必须写进Git配置见方式三。3.4 方式三Git全局exclude文件个人私藏规则的正确位置Git自带一个全局的忽略文件路径在用户主目录下的.gitconfig同目录通常叫.gitignore_global。在Windows下一般是C:\Users\你的用户名\.gitignore_global在macOS/Linux下是~/.gitignore_global你可以通过命令设置让Git使用这个文件作为全局忽略规则git config --global core.excludesfile ~/.gitignore_global然后编辑~/.gitignore_global内容格式和.gitignore完全一样。往里面写入你个人不希望提交、但又不适合通过项目.gitignore影响团队的内容。这个方式本质上是补足“方式二”的盲区一旦写入全局exclude文件Git会真正忽略这些文件不会有提交上去的风险。三种方式的效果对比如下表配置位置影响范围是否随仓库分发适合内容项目.gitignore所有克隆该项目的人是编译产物、IDE配置、日志等团队统一的规则IDEA File Types 忽略仅当前电脑当前IDEA否本地临时文件、测试数据等不想让IDE显示的内容Git全局excludesfile当前电脑所有Git仓库否个人习惯、开发者本机私有配置3.5 .gitignore 语法规则精讲核心的10条.gitignore的语法不复杂但很多人只会写最基础的target/遇到稍微复杂的需求就懵了。我把实际开发中最常用的语法规则整理一遍每条配合一个例子。空白行不匹配任何文件纯粹为了可读性分隔。井号开头注释行#后面的内容不会被解析。但如果你想匹配的文件名本身就带#需要用\#转义。斜杠开头指定匹配根目录下的相对路径。比如/target/只匹配项目根目录下的target目录不匹配src/main/resources/target/。目录分隔符结尾末尾带/表示只匹配目录如build/只忽略叫 build 的目录不忽略叫 build.txt 的文件。星号匹配零个或多个字符但不匹配目录分隔符。*.log会忽略所有扩展名为.log的文件。双星号abc/**匹配abc目录下所有文件和目录包括子目录。a/**/b匹配a/b、a/x/b、a/x/y/b等。**/foo匹配任意层级下的foo文件或目录。问号匹配单个字符。?est能匹配test、best但不匹配abest。方括号匹配字符集合。[Tt]emp匹配Temp和temp[0-9]匹配任意数字。叹号取反!开头表示重新包含被前面的规则忽略的文件。比如# 忽略所有 jar 文件 *.jar # 但保留 lib/ 目录下的 fixed.jar !lib/fixed.jar叹号取反的限制如果父目录已经被忽略了那么子目录下的取反规则不会生效。例如你忽略了build/那么!build/keep.txt是无效的因为Git不会进入build目录内部去匹配。要抵消这个限制你需要先不忽略父目录即build/* !build/keep.txt这个“父目录被忽略导致子目录取反失败”的坑我亲眼见过同事排查了一下午。记住这个原则你不能重新包含一个处于被忽略目录内部的文件除非你先用取反规则恢复了那个目录本身或者调整忽略位置到父目录内部。4. 误提交的补救从仓库中移除已跟踪文件的实操配置忽略了文件但如果在这之前已经有一些文件被提交进了Git仓库那么写了.gitignore也没用——忽略规则只对未跟踪文件生效已经跟踪的文件不会自动从仓库中移除Git会继续追踪它们的变化。这是所有人都会遇到的一个坎也是忽略文件配置中最容易被忽略的盲区。4.1 你已经把 target、.idea 都推上去了怎么办常见症状是你在.gitignore里写了target/但IDEA文件面板里target目录依然是蓝色或绿色修改依然会被追踪。原因就是上面的原则文件已经进入版本控制了。解决办法是先把这些文件从Git的追踪中移除然后再靠.gitignore规则拦截。IDEA的操作方式右键需要移除的目录或文件 - Git - Remove...但要注意Remove的默认行为是把文件从磁盘上也删除。如果只想从Git追踪中移除、保留本地文件需要在弹出的窗口中取消勾选Delete local copy。IDEA 2020以上版本还支持直接操作右键 -Git - Add to .gitignoreIDEA会自动更新忽略文件但已跟踪文件的处理上依然需要注意细节。更精确的做法是在IDEA底部的Terminal里执行命令git rm -r --cached target/ git rm --cached .idea/-r表示递归处理目录--cached是关键参数意为只从索引也就是Git追踪记录中移除保留工作区文件。执行完git rm -r --cached之后再用git commit提交一次提交信息写chore: remove target/ from version control这时目标目录就从仓库里消失了但磁盘上的文件还在。Gitee或者GitHub仓库里的历史记录中目标文件还是会存在因为历史提交记录不会被抹掉。如果你有强烈的清理历史记录的需求比如之前误提交了包含密码的配置文件常规做法是使用git filter-branch或git filter-repo重写历史但这会改变提交哈希影响所有协作者操作前务必和组织里的成员同步。4.2 移除之后提交一次背景色会告诉你一切完成git rm -r --cached并提交后你再看IDEA的Project面板会发现对应目录的颜色变成了灰色此时说明Git已经不再追踪它.gitignore规则接上了。这个“颜色变灰”的瞬间就是整条链路最终打通的标志。整个状态的流转过程是这样状态执行动作结果已跟踪文件变蓝/绿git rm -r --cached target/Git不再追踪本地文件保留未跟踪但未被忽略在.gitignore中写入target/文件变灰Git完全忽略已跟踪且被忽略修改文件Git不会报告变更有的同事会问我直接改.gitignore把target/写进去再手动从仓库里删掉目标文件不行吗行但很容易误删本地文件。用--cached是最稳妥的路径这也是为什么我建议大家在IDEA里操作时只要能开Terminal就直接用命令处理这个场景——IDEA的图形界面在“保留本地文件但移除追踪”这个意图上表达得不够直接。4.3 一个新文件的正确添加姿势这里再补充一个新文件添加的问题。很多人习惯在IDEA里直接右键文件 -Git - Add把新文件加入追踪。但如果你在新文件中写了一些本不该进仓库的内容此时再改.gitignore就晚了它已经被追踪了。正确顺序应该是写代码写好之后先在本地跑通。确认文件是否应该进仓库如果不需要先在.gitignore里写好规则。再执行Add Commit。养成这个习惯之后你就不太会因为“哎呀忘了写ignore把target推上去了”这种问题失眠了。5. 冲突与分支整合理Git之后必然会遇到的高频场景日常开发中单打独斗的项目用Git其实非常简单——提交、推送、完事。但如果你在一个团队里干活冲突处理就是绕不开的一道坎。IDEA把冲突处理的交互做得算是不错但前提是你理解冲突的本质。5.1 冲突是怎么产生的从“两个人改了同一行”说起先说一个反直觉的结论Git本身非常擅长合并代码它根本不是“一遇到不同就报冲突”。两个分支各自新增了两个文件Git能自动合并一个人改了一个文件的上半部分另一个人改了同一个文件的下半部分Git也无压力。真正触发冲突的是两个人修改了同一个文件的同一块区域——Git不知道哪个版本才是正确的它是“不猜的”所以把问题抛给人。唯一能让Git“猜”的情况是双方改的改动完全没有重叠这时Git自动合并就能成功。理解这一点你就知道为什么有些冲突明明看起来“很小”却需要人来处理——因为语义冲突是无法通过算法判断的。在IDEA中遇到冲突时会弹出Git Merge Conflicts对话框列出所有冲突文件。点开某个文件后IDEA会提供一个三栏对比界面左侧是本地版本Your Version / Local右侧是远端版本Their Version / Remote中间的Result是最终合并结果下方还有一排操作按钮和可以一键接受左侧或右侧的某个块X可以删除某个块手动编辑中间的结果区域也可以。处理完一个文件后标记为Merged就行。5.2 合并操作的窗口期IDEA中的Merge、Rebase与Cherry-PickIDEA集成Git之后分支管理的操作入口通常是右下角的分支名点击后会弹出Git Branches窗口。这里能看到所有本地分支和远程分支。分支合并的核心操作是Merge into Current先切换到目标分支比如切到dev然后在分支列表里选test分支点Merge into Current就能把test合进dev。这里的细节在于你要分清楚“谁合到谁”先切到接收方再选择来源方。方向反了后果就是你的分支被别人代码覆盖了。相比MergeRebase的操作理解起来更抽象。简单说Merge是“合并记录”Rebase是“重演我的提交”。日常开发中我一般建议自己一个人待在特性分支上时用Rebase拉取最新的dev代码保持提交历史是一条干净的直线多人协作的分支合并用Merge更保险因为提交记录是真实的回滚也更方便。IDEA还提供了一个比较实用的功能Cherry-Pick翻译过来是“精选提交”。当你只需要把某一次提交挪到另一个分支时在Git日志面板里右键某次提交选择Cherry-Pick就能把这次提交复制到当前分支。这个操作在处理“哎我这个修改其实应该放在另一个分支上”的场景时非常管用不需要重新手改一遍代码。5.3 处理冲突时最耗时的是“上下文”不是冲突本身实际开发中IDEA解析冲突很快点几下鼠标就合并完了真正耗时的不是技术操作而是理解双方为什么要这么改。我的经验是拿到一个冲突文件先看提交历史搞清楚双方各自的提交记录和Commit Message再看代码上下文。很多情况下一方是“修了一个bug”另一方是“重构了一个方法”两者其实可以优雅共存——只是Git算法不知道而已。IDEA里查看某一行代码最近一次是什么时候改的光标定位到该行后右键 -Annotate能显示每行代码的最近提交人、提交时间和Commit Message。这个功能在处理冲突时几乎是必备的花一分钟看下提交历史就能少花半天去猜对方的意图。5.4 Stash的使用临时切分支前的保命技能合并分支前你经常会遇到一个场景当前分支改到一半突然要切去另一个分支看问题。但此时本地有未提交的修改直接切换分支Git会因为你当前分支有未提交改动而拒绝切换或者把改动带到另一个分支上去两种情况都可能引发混乱。正确做法是使用Stash暂存。在IDEA里Git - Uncommitted Changes - Stash Changes填入一个备注信息IDEA会把当前未提交的修改保存到一个临时区然后你的工作区就干净了。等切回来时再执行Git - Uncommitted Changes - Unstash Changes就能恢复到原来的状态。可能有读者会说“我直接把改动放到一个临时分支不就行了”但Stash的意义在于它不改变分支结构操作路径最短而且在处理“临时切分支看东西”这个场景时Stash是最省心的。需要注意的是Stash保存的改动在多个分支间是全局的恢复时要注意选择正确的Stash记录别拿错了。6. 平时用得上的几个IDEA Git技巧日志、回滚与快捷键大框架讲完了最后把我在实际使用中觉得特别好用的几个细节挑出来。这些不算“必须”但用上之后体验会好很多。6.1 Git日志面板的打开方式和查看技巧IDEA的Git日志面板不只是“看日志”那么简单。快捷键是Alt9Windows或Cmd9macOS或者点击IDEA底部工具窗口栏的Git标签。默认情况下日志面板显示所有分支的提交历史。这里我建议你打开Branches过滤器只显示当前分支的提交。尤其是项目大、提交频繁的场景如果不做过滤一眼望过去全是别人的提交记录找自己的提交得翻半天。另一个隐藏功能是双击某次提交右侧会显示这次提交涉及的所有文件变更列表。再双击某个文件会打开该文件的改动对比视图。这比“在项目面板里找到这个文件再查看历史”快多了。在日志面板右键某次提交还有几个很有意思的操作Checkout Revision检出该提交用于临时查看历史版本、Create Branch from Here从该提交创建新分支用于在历史位置开分支、Copy Revision Number复制这次提交的哈希值用于在Issue系统里做关联。6.2 回滚的三种层次Discard、Reverse Commit与Reset回滚是另一个高频操作但很多人分不清三种回滚的区别或者更准确地说他们不知道IDEA提供了三个不同力度的回滚工具。第一种Discard丢弃未提交的修改。在Commit窗口的变更文件列表里右键某文件选Discard或者直接在编辑器里右键 -Local History - Revert。这个操作的语义是“放弃当前工作区的修改回到最近一次提交的状态”。适合你改了一半发现改了思路想从头再来。第二种Reverse Commit反向提交。在Git日志面板里右键某次已经推送的提交选Revert CommitIDEA会创建一个新提交内容恰好是这次提交的反向操作。这个操作不会修改历史记录而是把“撤销”本身做成了一个新的提交。用于撤销已推送的提交时不破坏团队协作者的仓库状态。第三种Reset重置。在日志面板右键某次提交选Reset Current Branch to Here弹窗里有三种模式Soft保留改动所有变更回到暂存区。Mixed保留改动但所有变更回到未暂存状态。Hard彻底丢弃所有改动工作区强制回到选中的提交状态。个人强烈建议只在处理自己本地未推送的提交时使用Hard模式已经推送的提交一律用Reverse Commit或新建提交回滚不然你的仓库历史和远端对不上别人一Pull就会报错。6.3 快捷键合集整理一批我日常用得最顺手的快捷键都是IDEA集成Git后的高频操作。注意不同平台快捷键有差异Windows/Linux写在一起macOS单独标注。操作Windows / LinuxmacOS提交变更CtrlKCmdK推送CtrlShiftKCmdShiftK更新项目PullCtrlTCmdTGit日志面板Alt9Cmd9查看分支操作Control~部分版本为CtrlShift~Control~快速切换分支CtrlShift方向键打开分支列表CmdShift方向键有几个快捷键在不同版本IDEA里定义略有差异如果你发现按了没反应去Keymap设置里搜“Git”就能看到当前版本的实际绑定。6.4 “只忽略本文件不忽略同类型文件”的三种写法我还想再补充一个.gitignore里比较实用的小知识有些场景下你想忽略一个具体的文件但不想影响同一目录下其他同名同类型文件。写死路径就可以/config/database.local.properties但如果你希望这个“只忽略本文件”的规则能匹配多个目录下的同名文件写成**/database.local.properties还有一个更精准的写法只忽略根目录下的特定文件/database.local.properties这三种写法覆盖面从小到大分别是“单个目录单个文件”“任意目录下同名文件”“仅根目录下该文件”。实际使用中我经常用第二种因为很多框架约定以.local、.dev作为后缀的配置文件不需要进入仓库配一个模式就全挡住了。7. 最后聊几句我的日常习惯写到这儿IDEA整合Git和忽略文件配置的主干内容已经讲完了。最后分享几个我在实际开发中沉淀下来的小习惯都是踩过坑之后长记性才养成的第一新项目启动的第一件事先写.gitignore再写代码。哪怕项目只写了十行代码也先把忽略规则建好。这事一旦晚做后续不管是用git rm --cached还是重写提交历史都会浪费至少半小时。第二IDEA的Commit窗口里的Options区域有一个TODO检查框提交前可以点一下它会扫描你代码里留着的TODO注释提醒你别把写着“这里还有bug没处理”的代码提交上去。这个功能很多人不知道很好用。第三为了一次能“看明白”项目的所有变更我习惯把IDEA的Diff面板的侧边栏调成只看结构变化这样相当于把“改了哪些方法”“新增了哪些方法”列出来比逐行看代码更直观。第四git rm -r --cached .这个命令要谨慎使用。它的效果是让整个项目的所有文件都从Git追踪中退出但保留本地文件。有些人的.gitignore写得不好就干脆用这个命令“重置”一次追踪状态再配合新的忽略规则重新git add -A把所有应跟踪文件加回来。理论上可行但如果项目协作人多操作不当会把别人的持续集成触发一堆问题。说回忽略文件这件事本身它其实反映了Git的一个核心思想Git只管你要它管的文件。把编译产物和本地配置文件交给本地把源码和团队约定交给仓库各归其位才能真正让版本管理成为开发效率的助力而不是负担。希望这篇内容能帮你把IDEA和Git的配合理顺少走几步弯路。
1. 从下载到IDEA识别Git环境准备链路上的细节坑先把话说在前面网上搜“IDEA整合Git”百分之八十的教程默认你的电脑上已经装好了Git然后直接打开IDEA开始配置。但以我这些年帮同事排查问题的经验来看很多“配置不成功”的案例源头其实在更早的位置——Git本身没装对或者装了但IDEA压根没认出来。所以第一步我们把这条链路完整捋一遍确保地基没问题。1.1 Git安装时最容易忽略的两个选择项Git的Windows安装包是个exe一路Next似乎谁都会但有两个选项会直接影响IDEA的集成体验。第一个是安装路径。官方默认路径通常是C:\Program Files\Git这个路径中间带空格理论上没问题但个别Windows环境下的脚本解析空格时容易出幺蛾子。如果你是新手建议直接装到不带空格的路径比如D:\Git或者C:\Git。你可能会觉得我在小题大做但等到后面配置Gitee密钥或者写自动化脚本时路径问题真的会跳出来咬你一口。第二个是安装过程中遇到Adjusting your PATH environment这一步务必选第二项或第三项Git from the command line and also from 3rd-party software而不是第一项Use Git from Git Bash only。选第一项的话Git命令只能在Git Bash里用Windows的CMD和IDEA的终端都调用不到git命令后续会非常难受。安装完成后打开CMD或者PowerShell输入git --version如果能正常输出版本号说明这一步走通了。我见过不少同事装完Git从来不验证直接去IDEA里配置结果IDEA提示找不到Git可执行文件回头才发现在PATH那一环就选错了。1.2 IDEA中配置Git的准确操作路径IDEA检测Git并不需要重启它是动态感知的。打开IDEA依次进入File - Settings - Version Control - Git在右侧的Path to Git executable这一栏IDEA通常会自己探测到Git的安装路径。如果这一栏是空的或者提示Invalid path点击旁边的...按钮手动选择Windows下一般是C:\Program Files\Git\bin\git.exe或你自定义路径下的git.exemacOS下一般是/usr/local/bin/git或/opt/homebrew/bin/git取决于你用什么方式安装的选完之后点右下角的Test按钮。如果IDEA弹出Git executed successfully说明IDEA已经正确识别到Git。这里我想多说一句Git路径必须精确到git.exe这个文件不是Git安装根目录也不是bin目录。曾经有位同事把路径填成了D:\GitIDEA倒是不报错但所有Git操作都失效这就是路径层级没搞对。1.3 Windows下最隐蔽的坑凭据管理器与换行符安装和识别都搞定了但在实际提交代码前Windows用户还有两个默认行为要调整否则后面迟早要踩坑。第一个是凭据管理器。Git默认会启动Git Credential Manager帮你记住Gitee或GitHub的账号密码。这本来是方便但麻烦在于如果你切换了账号或者密码改了凭据管理器会一直用旧凭据去认证导致你反复提交失败而IDEA又只会报一个笼统的Authentication failed。真遇到这个情况去Windows的“凭据管理器”里把旧凭据删掉重新认证一次就好。第二个是换行符转换。Windows的换行符是CRLFLinux和macOS是LF。Git默认在提交时会自动把CRLF转换成LFcore.autocrlftrue在检出时再把LF转回CRLF。理论上这能避免跨平台换行符问题但在一些老项目里策略配置不当会导致整个文件显示为已修改而git diff又看不出任何差异。个人习惯是把它设置成git config --global core.autocrlf input意思是不管在什么平台提交到仓库时统一转成LF检出时不做转换。这样写代码的人不会因为换行符被反复折磨。2. 先用起来IDEA中Git的日常提交工作流环境通了之后核心操作就集中在几个高频动作上。先别急着上手我们花两分钟把IDEA里Git的几个按钮和概念对着图认一遍不然你会不知道什么时候该用哪个功能。2.1 初始化仓库与第一次提交如果你手头是一个新项目还没有任何Git关联操作窗口在IDEA的顶部菜单VCS - Enable Version Control Integration弹出菜单选择Git然后点OK。这一步做完IDEA的右上角会出现通常说的Git工具栏——一个绿色的对勾Commit、一个蓝色的向下箭头Update、一个向上的箭头Push以及分支名下拉框。但这里有个新手非常容易犯的错Enable Version Control Integration之后项目里的文件并不会立即显示为Git管理的状态你需要先做一次Commit才能让所有文件进入Git的追踪视野。在IDEA里首次提交的路径是右键项目根目录 - Git - Commit Directory...接着IDEA会弹出一个Commit窗口这里会列出所有变更文件、改动内容diff、以及下方的Commit Message输入框。第一次提交Message一般写Initial commit就行。点Commit按钮右下角出现Committed successfully这个项目才真正完成了Git的初始化。需要注意一个细节Commit窗口下方有一个Commit按钮旁边的下拉小箭头展开后能看到Commit and Push...。第一次提交不用选这个因为此时远端仓库还没配置Push会失败。先本地提交后面关联远端再Push。2.2 关联远程仓库并完成首次推送关联远程仓库本质有两种操作顺序不同的人习惯不同效果一致一种是先在Gitee或GitHub上建一个空仓库拿到仓库地址在IDEA里执行Git - Manage Remotes添加origin地址然后执行Push。另一种是从远端仓库拉下来再填代码也就是Git - Clone...输入仓库地址直接克隆。第二种方式更适合加入已有项目我们重点说第一种。在Gitee上新建仓库时它会给出一串地址比如https://gitee.com/yourname/yourproject.git拿到地址后IDEA操作路径Git - Manage Remotes... - 点击 号 - Name填originURL填上面的地址 - OK然后执行推送点工具栏上的向上箭头或者快捷键CtrlShiftKIDEA会让你选择要推送的分支确认后开始Push。首次Push时IDEA会弹出窗口要求你输入Gitee/GitHub的账号密码或者跳转浏览器完成OAuth认证。验证通过后代码就推上去了。之后你打开Gitee仓库页面能看到IDEA生成的.gitignore文件了吗大概率看不到。因为IDEA默认不会帮你生成这个文件除非你用的是Spring Initializr这类脚手架创建的项目。这就引出了本文的核心问题忽略文件到底该怎么配。2.3 IDEA里“变色”的文件到底代表什么状态细节操作之前先把文件颜色的逻辑说清楚因为这个搞不懂你会觉得Git的状态提示完全不可理喻。IDEA的Project面板中不同颜色的文件代表不同的Git状态红色未加入版本控制也就是Untracked文件。新创建的文件默认都是这个状态。绿色已加入版本控制但尚未提交的新文件。蓝色已加入版本控制且本地修改过但没有提交。灰色被忽略的文件通常是.gitignore配置之后出现的效果。白色/普通已提交且工作区干净。这个颜色体系一旦建立起来你扫一眼整个项目面板就知道哪些文件动了、哪些文件是新的、哪些文件不用管。而忽略文件的作用恰恰就是让我第一眼扫过去时不会被target目录下几百个编译产物干扰。3. 重头戏忽略文件配置的三种思路和.gitignore语法精讲现在说到正题了。IDEA里配置Git忽略文件其实不止一种方式不同方式适用的场景和持久化程度完全不同。如果你在网上搜过会发现答案五花八门——有人让你装插件有人让你改IDEA设置还有人让你在项目根目录建文件。这些都对但背后的逻辑和适用边界不一样。我按实际开发中的使用频率和重要程度从最常用的开始讲。3.1 为什么必须忽略这些文件一个真实的仓库崩溃案例先讲一个我实际遇到过的案例。有个同事负责的项目代码量不算大但有一天代码托管平台提示仓库体积超过500MB。我们查了一圈发现问题出在target/目录里的编译产物被反复提交、反复变更Git仓库的.git目录膨胀到一个离谱的体积。更麻烦的是每次IDE编译完target/下面大量文件的修改时间变化会让Git以为文件有改动整个项目面板一片蓝色看起来像改了几百个文件实际上代码一行没动。这个案例说明一个道理忽略文件的本质不是“减少麻烦”而是保护仓库的纯净度。仓库里应该只有源码、配置文件和文档编译产物、IDE配置、系统文件这些都不应该进来。常见的需要忽略的文件分几类编译产物Java项目里的target/、out/目录前端项目里的node_modules/、dist/、build/目录。IDE本地配置IDEA产生的.idea/目录、*.iml文件Eclipse产生的.classpath、.project、.settings/目录。这些是个人开发环境差异不应该提交到仓库。有一个例外如果你用了类似EditorConfig之类的团队统一配置需要提交的部分要单独保留。系统文件.DS_StoremacOS、Thumbs.dbWindows。日志和临时文件*.log、*.tmp、*.cache。环境相关配置.env环境变量、application-local.yml本地私有配置等这些往往包含数据库密码等敏感信息绝不能进仓库。3.2 方式一在项目根目录创建 .gitignore 文件最推荐随仓库分发这是最标准、最推荐的做法。在项目根目录创建一个名为.gitignore的文件把要忽略的目录或文件按照语法规则写进去提交到仓库全队共享一份规则。IDEA创建这个文件有两种路径。一种是在项目根目录右键 -New - File输入文件名.gitignore注意IDEA可能会提示你安装.gitignore插件不装也能写文件装了有语法高亮和自动补全体验更好。另一种是使用IDEA自带的模板生成功能右键项目根目录 -New - .ignore file - .gitignoreIDEA会弹出一个模板选择窗口支持从几百种模板里勾选然后自动生成配置文件。以Java项目为例一份典型的.gitignore长这样# Compiled class file *.class # Log file *.log # BlueJ files *.ctxt # Mobile Tools for Java (J2ME) .mtj.tmp/ # Package Files # *.jar *.war *.nar *.ear *.zip *.tar.gz *.rar # virtual machine crash logs hs_err_pid* # Maven target/ # IDEA .idea/ *.iml # Eclipse .classpath .project .settings/ bin/ # OS .DS_Store Thumbs.db # Env .env application-local.yml写完保存后IDEA里面对应文件会变成灰色也就是已忽略状态。这个文件本身要提交到Git仓库里这样团队其他人拉下代码后也会自动应用同一套忽略规则。需要额外说明的是target/可以加也可以选择不加库文件的正则。从惯例来说target/是Maven项目的标准输出目录Java项目几乎人人都在忽略行里写它。而*.jar和*.war这种要看你项目的依赖管理方式如果你用的是Maven或Gradle依赖包不需要提交那就忽略如果你维护的是传统Web项目是手动拷jar包到WEB-INF/lib下的那就千万不能忽略否则别人拉下代码跑不起来。3.3 方式二IDEA设置里配置全局忽略解决“自己的文件不想让IDEA扫描”的问题.gitignore的规则是随项目走的但它有一个覆盖不到的场景你不想让某个文件进入仓库但又不想把这个规则提交到项目.gitignore里去影响团队其他人。比如你自己本地的application-dev.yml数据库地址团队其他人用的是另一套配置。这时候可以用IDEA自己的忽略机制。路径是File - Settings - Editor - File Types在右侧Recognized File Types列表中选中Ignore files and folders然后在下面的输入框中追加你要忽略的文件名或目录名用英文分号分隔。比如追加application-dev.yml;这里有个坑IDEA的这项设置是纯IDE层面的忽略只是让IDEA不再追踪和显示这些文件不会影响Git的行为。也就是说如果Git之前已经跟踪了application-dev.ymlIDEA忽略它并不等于Git忽略它推送时它还是会被推上去。真正的全局忽略必须写进Git配置见方式三。3.4 方式三Git全局exclude文件个人私藏规则的正确位置Git自带一个全局的忽略文件路径在用户主目录下的.gitconfig同目录通常叫.gitignore_global。在Windows下一般是C:\Users\你的用户名\.gitignore_global在macOS/Linux下是~/.gitignore_global你可以通过命令设置让Git使用这个文件作为全局忽略规则git config --global core.excludesfile ~/.gitignore_global然后编辑~/.gitignore_global内容格式和.gitignore完全一样。往里面写入你个人不希望提交、但又不适合通过项目.gitignore影响团队的内容。这个方式本质上是补足“方式二”的盲区一旦写入全局exclude文件Git会真正忽略这些文件不会有提交上去的风险。三种方式的效果对比如下表配置位置影响范围是否随仓库分发适合内容项目.gitignore所有克隆该项目的人是编译产物、IDE配置、日志等团队统一的规则IDEA File Types 忽略仅当前电脑当前IDEA否本地临时文件、测试数据等不想让IDE显示的内容Git全局excludesfile当前电脑所有Git仓库否个人习惯、开发者本机私有配置3.5 .gitignore 语法规则精讲核心的10条.gitignore的语法不复杂但很多人只会写最基础的target/遇到稍微复杂的需求就懵了。我把实际开发中最常用的语法规则整理一遍每条配合一个例子。空白行不匹配任何文件纯粹为了可读性分隔。井号开头注释行#后面的内容不会被解析。但如果你想匹配的文件名本身就带#需要用\#转义。斜杠开头指定匹配根目录下的相对路径。比如/target/只匹配项目根目录下的target目录不匹配src/main/resources/target/。目录分隔符结尾末尾带/表示只匹配目录如build/只忽略叫 build 的目录不忽略叫 build.txt 的文件。星号匹配零个或多个字符但不匹配目录分隔符。*.log会忽略所有扩展名为.log的文件。双星号abc/**匹配abc目录下所有文件和目录包括子目录。a/**/b匹配a/b、a/x/b、a/x/y/b等。**/foo匹配任意层级下的foo文件或目录。问号匹配单个字符。?est能匹配test、best但不匹配abest。方括号匹配字符集合。[Tt]emp匹配Temp和temp[0-9]匹配任意数字。叹号取反!开头表示重新包含被前面的规则忽略的文件。比如# 忽略所有 jar 文件 *.jar # 但保留 lib/ 目录下的 fixed.jar !lib/fixed.jar叹号取反的限制如果父目录已经被忽略了那么子目录下的取反规则不会生效。例如你忽略了build/那么!build/keep.txt是无效的因为Git不会进入build目录内部去匹配。要抵消这个限制你需要先不忽略父目录即build/* !build/keep.txt这个“父目录被忽略导致子目录取反失败”的坑我亲眼见过同事排查了一下午。记住这个原则你不能重新包含一个处于被忽略目录内部的文件除非你先用取反规则恢复了那个目录本身或者调整忽略位置到父目录内部。4. 误提交的补救从仓库中移除已跟踪文件的实操配置忽略了文件但如果在这之前已经有一些文件被提交进了Git仓库那么写了.gitignore也没用——忽略规则只对未跟踪文件生效已经跟踪的文件不会自动从仓库中移除Git会继续追踪它们的变化。这是所有人都会遇到的一个坎也是忽略文件配置中最容易被忽略的盲区。4.1 你已经把 target、.idea 都推上去了怎么办常见症状是你在.gitignore里写了target/但IDEA文件面板里target目录依然是蓝色或绿色修改依然会被追踪。原因就是上面的原则文件已经进入版本控制了。解决办法是先把这些文件从Git的追踪中移除然后再靠.gitignore规则拦截。IDEA的操作方式右键需要移除的目录或文件 - Git - Remove...但要注意Remove的默认行为是把文件从磁盘上也删除。如果只想从Git追踪中移除、保留本地文件需要在弹出的窗口中取消勾选Delete local copy。IDEA 2020以上版本还支持直接操作右键 -Git - Add to .gitignoreIDEA会自动更新忽略文件但已跟踪文件的处理上依然需要注意细节。更精确的做法是在IDEA底部的Terminal里执行命令git rm -r --cached target/ git rm --cached .idea/-r表示递归处理目录--cached是关键参数意为只从索引也就是Git追踪记录中移除保留工作区文件。执行完git rm -r --cached之后再用git commit提交一次提交信息写chore: remove target/ from version control这时目标目录就从仓库里消失了但磁盘上的文件还在。Gitee或者GitHub仓库里的历史记录中目标文件还是会存在因为历史提交记录不会被抹掉。如果你有强烈的清理历史记录的需求比如之前误提交了包含密码的配置文件常规做法是使用git filter-branch或git filter-repo重写历史但这会改变提交哈希影响所有协作者操作前务必和组织里的成员同步。4.2 移除之后提交一次背景色会告诉你一切完成git rm -r --cached并提交后你再看IDEA的Project面板会发现对应目录的颜色变成了灰色此时说明Git已经不再追踪它.gitignore规则接上了。这个“颜色变灰”的瞬间就是整条链路最终打通的标志。整个状态的流转过程是这样状态执行动作结果已跟踪文件变蓝/绿git rm -r --cached target/Git不再追踪本地文件保留未跟踪但未被忽略在.gitignore中写入target/文件变灰Git完全忽略已跟踪且被忽略修改文件Git不会报告变更有的同事会问我直接改.gitignore把target/写进去再手动从仓库里删掉目标文件不行吗行但很容易误删本地文件。用--cached是最稳妥的路径这也是为什么我建议大家在IDEA里操作时只要能开Terminal就直接用命令处理这个场景——IDEA的图形界面在“保留本地文件但移除追踪”这个意图上表达得不够直接。4.3 一个新文件的正确添加姿势这里再补充一个新文件添加的问题。很多人习惯在IDEA里直接右键文件 -Git - Add把新文件加入追踪。但如果你在新文件中写了一些本不该进仓库的内容此时再改.gitignore就晚了它已经被追踪了。正确顺序应该是写代码写好之后先在本地跑通。确认文件是否应该进仓库如果不需要先在.gitignore里写好规则。再执行Add Commit。养成这个习惯之后你就不太会因为“哎呀忘了写ignore把target推上去了”这种问题失眠了。5. 冲突与分支整合理Git之后必然会遇到的高频场景日常开发中单打独斗的项目用Git其实非常简单——提交、推送、完事。但如果你在一个团队里干活冲突处理就是绕不开的一道坎。IDEA把冲突处理的交互做得算是不错但前提是你理解冲突的本质。5.1 冲突是怎么产生的从“两个人改了同一行”说起先说一个反直觉的结论Git本身非常擅长合并代码它根本不是“一遇到不同就报冲突”。两个分支各自新增了两个文件Git能自动合并一个人改了一个文件的上半部分另一个人改了同一个文件的下半部分Git也无压力。真正触发冲突的是两个人修改了同一个文件的同一块区域——Git不知道哪个版本才是正确的它是“不猜的”所以把问题抛给人。唯一能让Git“猜”的情况是双方改的改动完全没有重叠这时Git自动合并就能成功。理解这一点你就知道为什么有些冲突明明看起来“很小”却需要人来处理——因为语义冲突是无法通过算法判断的。在IDEA中遇到冲突时会弹出Git Merge Conflicts对话框列出所有冲突文件。点开某个文件后IDEA会提供一个三栏对比界面左侧是本地版本Your Version / Local右侧是远端版本Their Version / Remote中间的Result是最终合并结果下方还有一排操作按钮和可以一键接受左侧或右侧的某个块X可以删除某个块手动编辑中间的结果区域也可以。处理完一个文件后标记为Merged就行。5.2 合并操作的窗口期IDEA中的Merge、Rebase与Cherry-PickIDEA集成Git之后分支管理的操作入口通常是右下角的分支名点击后会弹出Git Branches窗口。这里能看到所有本地分支和远程分支。分支合并的核心操作是Merge into Current先切换到目标分支比如切到dev然后在分支列表里选test分支点Merge into Current就能把test合进dev。这里的细节在于你要分清楚“谁合到谁”先切到接收方再选择来源方。方向反了后果就是你的分支被别人代码覆盖了。相比MergeRebase的操作理解起来更抽象。简单说Merge是“合并记录”Rebase是“重演我的提交”。日常开发中我一般建议自己一个人待在特性分支上时用Rebase拉取最新的dev代码保持提交历史是一条干净的直线多人协作的分支合并用Merge更保险因为提交记录是真实的回滚也更方便。IDEA还提供了一个比较实用的功能Cherry-Pick翻译过来是“精选提交”。当你只需要把某一次提交挪到另一个分支时在Git日志面板里右键某次提交选择Cherry-Pick就能把这次提交复制到当前分支。这个操作在处理“哎我这个修改其实应该放在另一个分支上”的场景时非常管用不需要重新手改一遍代码。5.3 处理冲突时最耗时的是“上下文”不是冲突本身实际开发中IDEA解析冲突很快点几下鼠标就合并完了真正耗时的不是技术操作而是理解双方为什么要这么改。我的经验是拿到一个冲突文件先看提交历史搞清楚双方各自的提交记录和Commit Message再看代码上下文。很多情况下一方是“修了一个bug”另一方是“重构了一个方法”两者其实可以优雅共存——只是Git算法不知道而已。IDEA里查看某一行代码最近一次是什么时候改的光标定位到该行后右键 -Annotate能显示每行代码的最近提交人、提交时间和Commit Message。这个功能在处理冲突时几乎是必备的花一分钟看下提交历史就能少花半天去猜对方的意图。5.4 Stash的使用临时切分支前的保命技能合并分支前你经常会遇到一个场景当前分支改到一半突然要切去另一个分支看问题。但此时本地有未提交的修改直接切换分支Git会因为你当前分支有未提交改动而拒绝切换或者把改动带到另一个分支上去两种情况都可能引发混乱。正确做法是使用Stash暂存。在IDEA里Git - Uncommitted Changes - Stash Changes填入一个备注信息IDEA会把当前未提交的修改保存到一个临时区然后你的工作区就干净了。等切回来时再执行Git - Uncommitted Changes - Unstash Changes就能恢复到原来的状态。可能有读者会说“我直接把改动放到一个临时分支不就行了”但Stash的意义在于它不改变分支结构操作路径最短而且在处理“临时切分支看东西”这个场景时Stash是最省心的。需要注意的是Stash保存的改动在多个分支间是全局的恢复时要注意选择正确的Stash记录别拿错了。6. 平时用得上的几个IDEA Git技巧日志、回滚与快捷键大框架讲完了最后把我在实际使用中觉得特别好用的几个细节挑出来。这些不算“必须”但用上之后体验会好很多。6.1 Git日志面板的打开方式和查看技巧IDEA的Git日志面板不只是“看日志”那么简单。快捷键是Alt9Windows或Cmd9macOS或者点击IDEA底部工具窗口栏的Git标签。默认情况下日志面板显示所有分支的提交历史。这里我建议你打开Branches过滤器只显示当前分支的提交。尤其是项目大、提交频繁的场景如果不做过滤一眼望过去全是别人的提交记录找自己的提交得翻半天。另一个隐藏功能是双击某次提交右侧会显示这次提交涉及的所有文件变更列表。再双击某个文件会打开该文件的改动对比视图。这比“在项目面板里找到这个文件再查看历史”快多了。在日志面板右键某次提交还有几个很有意思的操作Checkout Revision检出该提交用于临时查看历史版本、Create Branch from Here从该提交创建新分支用于在历史位置开分支、Copy Revision Number复制这次提交的哈希值用于在Issue系统里做关联。6.2 回滚的三种层次Discard、Reverse Commit与Reset回滚是另一个高频操作但很多人分不清三种回滚的区别或者更准确地说他们不知道IDEA提供了三个不同力度的回滚工具。第一种Discard丢弃未提交的修改。在Commit窗口的变更文件列表里右键某文件选Discard或者直接在编辑器里右键 -Local History - Revert。这个操作的语义是“放弃当前工作区的修改回到最近一次提交的状态”。适合你改了一半发现改了思路想从头再来。第二种Reverse Commit反向提交。在Git日志面板里右键某次已经推送的提交选Revert CommitIDEA会创建一个新提交内容恰好是这次提交的反向操作。这个操作不会修改历史记录而是把“撤销”本身做成了一个新的提交。用于撤销已推送的提交时不破坏团队协作者的仓库状态。第三种Reset重置。在日志面板右键某次提交选Reset Current Branch to Here弹窗里有三种模式Soft保留改动所有变更回到暂存区。Mixed保留改动但所有变更回到未暂存状态。Hard彻底丢弃所有改动工作区强制回到选中的提交状态。个人强烈建议只在处理自己本地未推送的提交时使用Hard模式已经推送的提交一律用Reverse Commit或新建提交回滚不然你的仓库历史和远端对不上别人一Pull就会报错。6.3 快捷键合集整理一批我日常用得最顺手的快捷键都是IDEA集成Git后的高频操作。注意不同平台快捷键有差异Windows/Linux写在一起macOS单独标注。操作Windows / LinuxmacOS提交变更CtrlKCmdK推送CtrlShiftKCmdShiftK更新项目PullCtrlTCmdTGit日志面板Alt9Cmd9查看分支操作Control~部分版本为CtrlShift~Control~快速切换分支CtrlShift方向键打开分支列表CmdShift方向键有几个快捷键在不同版本IDEA里定义略有差异如果你发现按了没反应去Keymap设置里搜“Git”就能看到当前版本的实际绑定。6.4 “只忽略本文件不忽略同类型文件”的三种写法我还想再补充一个.gitignore里比较实用的小知识有些场景下你想忽略一个具体的文件但不想影响同一目录下其他同名同类型文件。写死路径就可以/config/database.local.properties但如果你希望这个“只忽略本文件”的规则能匹配多个目录下的同名文件写成**/database.local.properties还有一个更精准的写法只忽略根目录下的特定文件/database.local.properties这三种写法覆盖面从小到大分别是“单个目录单个文件”“任意目录下同名文件”“仅根目录下该文件”。实际使用中我经常用第二种因为很多框架约定以.local、.dev作为后缀的配置文件不需要进入仓库配一个模式就全挡住了。7. 最后聊几句我的日常习惯写到这儿IDEA整合Git和忽略文件配置的主干内容已经讲完了。最后分享几个我在实际开发中沉淀下来的小习惯都是踩过坑之后长记性才养成的第一新项目启动的第一件事先写.gitignore再写代码。哪怕项目只写了十行代码也先把忽略规则建好。这事一旦晚做后续不管是用git rm --cached还是重写提交历史都会浪费至少半小时。第二IDEA的Commit窗口里的Options区域有一个TODO检查框提交前可以点一下它会扫描你代码里留着的TODO注释提醒你别把写着“这里还有bug没处理”的代码提交上去。这个功能很多人不知道很好用。第三为了一次能“看明白”项目的所有变更我习惯把IDEA的Diff面板的侧边栏调成只看结构变化这样相当于把“改了哪些方法”“新增了哪些方法”列出来比逐行看代码更直观。第四git rm -r --cached .这个命令要谨慎使用。它的效果是让整个项目的所有文件都从Git追踪中退出但保留本地文件。有些人的.gitignore写得不好就干脆用这个命令“重置”一次追踪状态再配合新的忽略规则重新git add -A把所有应跟踪文件加回来。理论上可行但如果项目协作人多操作不当会把别人的持续集成触发一堆问题。说回忽略文件这件事本身它其实反映了Git的一个核心思想Git只管你要它管的文件。把编译产物和本地配置文件交给本地把源码和团队约定交给仓库各归其位才能真正让版本管理成为开发效率的助力而不是负担。希望这篇内容能帮你把IDEA和Git的配合理顺少走几步弯路。
