简介：面向从Eclipse切换到IntelliJ IDEA的Java开发者，这份PDF资料系统讲解了从Git拉取Maven项目的详细步骤，针对性解决刚接触新版IDE时在克隆、导入、依赖同步等环节的常见困惑。资源为单个PDF文档，压缩包约526KB，内容精炼，适合放在手边随时查阅。目前已有两万二千二百四十九人学习下载，是IDEA入门者中口碑不错的实操参考。文档完整覆盖了从版本控制检出项目、克隆Git仓库、导入外部模型并选择Maven构建工具、通过pom.xml管理依赖等流程；特别提醒导入时项目路径与工程存放目录的区别，并给出了导入后若依赖未自动下载时右键pom.xml重新导入的排错思路。结合界面截图与目录结构说明，能帮助读者一次理清拉取Maven项目的关键节点，避免因选项或路径错误反复折腾，从而更快地在本地建立起可运行的Maven工程。

1. 从 Git 拉取 Maven 项目：别把 IDEA 当成 Eclipse 用

很多从 Eclipse 转 IntelliJ IDEA 的人，第一周最懵的不是语法，而是“项目到底怎么进到工具里”。Eclipse 时代习惯 File -> Import -> Existing Projects into Workspace，到了 IDEA 里全变成了 Checkout from Version Control，后面还跟着一个 “Import project from external model”，一下子就把人绕晕了。说得直白一点，从 Git 拉取 Maven 项目到 IDEA 就是三个动作：先确认本机 Git 和 Maven 环境就绪，再从版本控制里把代码 clone 到本地，最后让 IDEA 用 Maven 的方式把 pom.xml 解析成一个工程。整个过程大部分失败都发生在第二步和第三步的参数填写上，尤其是“项目目录”和“存放目录”这两个概念，一旦填反，IDEA 会把整个仓库当成普通文件夹看待，Maven 工具窗口、依赖下载和编译按钮全部消失。这篇文章就按我实际操作的顺序，把每个参数、每个弹窗、每条坑都拆开讲一遍，适合身边刚装好 idea、git、maven 想拉公司项目的同事参考。

2. 拉取前的三件事：环境版本、仓库地址与 Git 凭据

2.1 先确认 IDEA、Git、Maven 三者的版本

我见过太多人上来就直接打开 IDEA 点 Git，结果 clone 提示找不到 git 可执行文件，或者拉下来之后才发现 Maven 没安装。所以我把环境检查放在第一步。首先是 idea 版本，新版本在 Welcome 界面直接有 Get from VCS，老版本叫 Checkout from Version Control，功能一致，不用纠结。其次是 Git，Windows 上装完 Git for Windows 之后，必须确认 PATH 里已经有 git 命令，否则 IDEA 里的版本控制功能会直接变灰。打开 Git Bash 或 CMD 输入git --version，能输出版本就说明安装成功。最后是 Maven，建议手动下载一个 apache-maven 解压到纯英文目录，例如D:\dev\apache-maven-3.8.8，不要用 IDEA 自带的那份 Maven，因为自带的版本会跟着 IDEA 升级，而你本地仓库里的 jar 缓存未必兼容，后面排查起来很头疼。

IDEA 内置了 JBR（JetBrains Runtime），但它只负责 IDE 自己的运行，不决定你拉下来的项目用哪个 JDK 编译。所以还要在命令行确认java -version，并把JAVA_HOME指向项目的目标 JDK 版本。这一步是很多老手忽略的，假设团队成员统一用 JDK 8，你本机默认 JDK 17，即使代码成功拉下来、pom.xml 也解析成功，编译时依然会报 Unsupported major version 或者 source option 过时的问题。主流的做法是：先装好 JDK，再装 Git 和 Maven，最后打开 IDEA，在三者的安装顺序上不要颠三倒四。顺序错了没关系，但环境变量必须配置齐全，否则后面每走一步都会被打断。

2.2 仓库地址的三种形态与分支选择

在 IDEA 的 Git 拉取界面里，URL 那栏填什么，取决于团队仓库的访问方式。最常见的是 HTTPS 地址，形如https://github.com/用户/仓库.git，这种地址只要账号权限到位就能直接 clone 下来。第二种是 SSH 地址，形如git@github.com:用户/仓库.git，它不需要每次输入密码，但前提是你在 IDEA 或命令行里把 SSH 私钥配置好。第三种是本地仓库路径，比如同一台机器上同事给你拷贝了一个裸仓库，直接填本地目录也行，不过这种情况在团队协作里比较少。表格如下：

这里要特别提醒一点：URL 填的是仓库的 clone 地址，不是浏览器里那个网页地址。很多人从浏览器复制https://gitee.com/xxx/project这种链接，填进去之后 IDEA 提示 “remote origin already exists” 或者 “repository not found”。原因很简单，仓库的首页地址不带.git后缀，且可能自动加上了登录态参数，IDEA 不认。对 Gitee 来说，项目主页上的“克隆/下载”按钮里才是标准地址，通常以.git结尾。分支选择上，如果仓库默认分支是 main，IDEA 会默认拉 main；如果团队还在用 master，需要在下拉列表里切换。我一般会在 clone 之前先到仓库网页上看一眼默认分支名，免得拉下来后又手忙脚乱。

2.3 凭据管理：为什么 Gitee 和 GitHub 的行为不一样

IDEA 内置的 Git 插件调用的是本机的 Git 凭据管理器。Windows 上常用 Git Credential Manager，macOS 上走 Keychain，Linux 上可能存明文或配合 libsecret。同样一个 HTTPS 地址，Gitee 和 GitHub 的认证规则完全不同。GitHub 从 2021 年开始不再接受账号密码的方式操作 Git 仓库，必须在网页端生成一个 Personal Access Token，然后把 token 当密码输入。Gitee 的 HTTPS 方式仍然可以用账号密码，但如果你们公司开启了双因子认证，密码会被强制换成动态令牌。遇到这类问题，最省事的方案是直接走 SSH 方式，在 Git Bash 里执行ssh-keygen -t rsa -b 4096 -C "you@example.com"生成密钥，再把公钥配置到 Gitee 或 GitLab 的 SSH 公钥列表里。

配置完密钥后，最好先验证一下通不通。命令行执行ssh -T git@gitee.com，出现欢迎语说明公钥已经生效，然后再回 IDEA 里拉取。如果 SSH 验证失败，IDEA 里填 SSH 地址时会反复弹出确认框，但就是连不上。还有个细节：IDEA 自己的 Git 配置和命令行 Git 配置是共享%USERPROFILE%\.gitconfig的，但 ssh-agent 里的密钥列表是独立进程，IDEA 某些版本不读取 ssh-agent，只读取~/.ssh/id_rsa。所以建议把密钥文件命名为默认的id_rsa或id_ed25519，别起花里胡哨的名字，否则可能出现命令行能拉、IDEA 拉不了的情况。这个坑不常见，但一旦出现非常费解。

3. Clone 到本地：Checkout from Version Control 的参数与目录结构

3.1 拉取入口到底在哪里

IDEA 的 Git 拉取入口在不同版本里有不同叫法，但逻辑一致。首次打开 IDEA，Welcome 界面上会有一个 “Get from VCS” 按钮，点击后进入版本控制克隆窗口。如果你已经打开了一个项目，想再拉一个新的仓库，可以在 File -> New -> Project from Version Control 里进入同一个窗口，也可以从顶部菜单 VCS -> Get from Version Control 进入。这里的 “VCS” 指的是 Version Control System，不单指 Git，但默认就是 Git。文章里提到的 “Check out from Version Control” 是旧版 IDEA 的菜单文案，功能完全一致，遇到哪个就用哪个。

真正容易困惑的是，IDEA 把“从 Git 仓库拉取代码”这件事当成一个新项目来创建，所以在克隆窗口里填写的目录就是未来这个工程所在的位置。这一点和 Eclipse 里直接把仓库导入 workspace 的思路不同，更接近“先下载代码，再决定怎么打开”的流程。我习惯在本地先建一个统一的工作区目录，例如D:\workspace，然后每个仓库在D:\workspace下新建一个子目录。这样 clone、备份、换机迁移都干净。

3.2 三个文本框的含义

克隆窗口里通常有三个关键参数：URL、Directory 和 Directory name。URL 就是上一节讲的仓库地址。Directory 是本地存放代码的父目录，Directory name 是最终的文件夹名称。很多人以为第三个不填也行，实际上不填时 IDEA 会默认用仓库名作为目录名，这可能和你项目模块名不一致。比如仓库名是mall-parent，里面又有mall-service、mall-admin，如果你把目录名改成server，后面的 Maven 导入反而会绕弯。所以建议第三个参数直接用仓库名。这三个参数的关系如下：

注意，Directory 填的是父目录，不是最终项目目录。举例来说，Directory 填D:\workspace，Directory name 填mall-parent，最终代码落在D:\workspace\mall-parent。如果有同事填成D:\workspace\mall-parent然后 Directory name 又填一遍，就会变成D:\workspace\mall-parent\mall-parent，虽然也能用，但后面每次打开项目都要多进一层，Maven 模块路径也会变长。这种问题属于低级失误，但确实能影响心情。

3.3 Clone 完成后的两个提示

点击 Clone 之后，IDEA 会先弹出进度条，连通后紧接着弹一个对话框，大体意思是“要不要打开这个 Git 项目”。这里有两个按钮，一个对应直接打开，另一个对应稍后处理。如果你选择了稍后处理，会回到欢迎页，需要再次从项目列表里找到刚才 clone 出来的目录。原文里描述的“问你是否设置导入的 git 项目为 idea 工程目录”就是这一步。我的习惯是直接选 Yes 或 Open 打开，让 IDEA 继续引导后续导入。第二个提示是 Trust Project，意思是要不要信任这个项目并执行它的构建脚本。公司内部项目一般直接 Trust，陌生项目建议先看一下结构再决定。这个提示在 IDEA 2021 之后常见，本质上是安全策略，不用过度紧张，但也不能闭着眼点。

3.4 拉下来的目录长什么样：Maven 工程结构

Git clone 只是把远程仓库里所有文件复制到本地，这一步并不会产生任何我们熟悉的“工程标记”。对 Maven 项目来说，clone 完成后的目录里一定有一个pom.xml，这是 Maven 的身份证。标准的单模块工程目录大致是：

project-root/ ├── pom.xml ├── src/ │ ├── main/ │ │ ├── java/ │ │ └── resources/ │ └── test/ │ ├── java/ │ └── resources/ └── .git/

如果是多模块聚合工程，根目录下通常也有一个 pom.xml，里面用<modules>声明子模块，每个子模块再有自己的 pom.xml。IDEA 正是通过识别这些 pom.xml 来决定是否把它当成 Maven 工程。所以拉取下来之后，先别急着点任何按钮，先在文件管理器里确认一下 pom.xml 位于哪一层。这一步确认清楚，后面导入 Maven 项目时选目录才不会被弹窗绕晕。多模块项目里常见的坑是：根目录有一个空的 pom.xml，业务代码全在子模块里，导入时只选了根目录，IDEA 虽然识别到聚合工程，但所有子模块无法被解析，报 “Module not specified”。遇到这种情况，要么选择子模块目录单独导入，要么检查根 pom 的<modules>是否正确声明了子模块路径。

4. 导入为 Maven 工程：external model 与两个目录的一次性选择

4.1 为什么必须走 Import project from external model

结束 Git 拉取后，IDEA 会进入一个项目导入的引导，其中一项是 “Import project from external model”。很多人不明白 external model 指的是什么，其实它就是独立于 IDEA 的工程描述方式，Maven 就是最典型的代表。Maven 通过 pom.xml 描述依赖、插件、打包方式，IDEA 通过 .iml 文件描述模块结构。两者之间需要做一次映射，把 pom.xml 的模型转换成 IDEA 能识别的模块。如果跳过这一步，直接把 pom.xml 拖进 IDEA，虽然也能看到代码文件，但不会有 Maven 工具窗口，也不会自动下载依赖，整个项目就是一个没有任何构建能力的代码文件夹。

选择 Maven 之后，IDEA 会读取 pom.xml 并建立模块列表。这里注意，新版 IDEA 还支持 Gradle、Eclipse 等模型的导入，如果选择错误，比如把 Maven 项目当成 Gradle 导入，后面会生成 gradle wrapper 目录，导致项目结构被污染。一般情况下都要选 Maven 然后点下一步。如果拉取后 IDEA 没有自动弹出导入向导，可以在 File -> Project Structure -> Modules 里手动添加 Module，选择 Import Module，再定位到 pom.xml 完成导入。这个手动路径就是传说中“右键项目出不来 Maven 选项”时的后悔药。

4.2 两个目录参数：工程存放目录和 Maven 项目目录

这是全文最核心的一个点，也是原文里特别强调的“红色区域”。clone 阶段填写的目录是“工程的存放位置”，也就是代码在磁盘上的落点。而导入 Maven 项目的向导里有一个字段填的是“Maven 项目目录”，它的含义是你想用哪个目录下的 pom.xml 作为 Maven 工程的根。多数人以为两者必然相同，其实不一定。单模块项目两者确实相同，但多模块仓库里，根目录的 pom.xml 只是聚合文件，实际需要导入的可能是服务端/或manager-server/这类子目录。错误示范是：在向导里填成了第一次 clone 时用的外部存储路径，导致导入后找不到 pom.xml。

判断标准只有一个：看这个目录下是否直接躺着 pom.xml。IDEA 不认“父目录里间接包含 pom”的路径，它只看你填的目录本身有没有 pom.xml。如果你想导入根目录聚合工程，必须在根目录下看到了 pom.xml 再点下一步。如果根目录下没有，就去子模块目录找，找到了那个目录再继续。原文中举的 Blog 例子就是这样，仓库根目录不是 Maven 项目，子目录 Blog 才是，所以在向导里要填的那个路径是.../Blog而不是仓库根路径。

4.3 JDK 与 Maven 运行器的第二个配置页

导入向导下一步会让你选择 Project SDK。这里选 JDK 时要注意，IDEA 会列出本机安装的所有 JDK，但默认可能指向 IDEA 自带的 JBR，那个不是标准 JDK。正确操作是点击 Add SDK -> JDK，定位到 JDK 安装目录，比如C:\Program Files\Java\jdk1.8.0_202。如果你的项目是 Java 8 写的老代码，这里选了 JDK 17，虽然也能导入，但 Maven 编译器插件默认 source/target 可能跟不上，pom.xml 里没显式声明时编译直接报错。导入完成后还可以在 Settings -> Build, Execution, Deployment -> Build Tools -> Maven -> Importing 里看到一个 Auto-import 选项，建议勾上。勾选后 pom.xml 一改动，IDEA 就会自动重新加载依赖，省去每次手动刷新。

Maven 运行器页面里还有三处值得配置：Maven home path、User settings file、Local repository。Maven home path 指向你下载的 Maven 解压目录；User settings file 指向conf/settings.xml；Local repository 是 jar 包缓存的本地仓库目录，默认是~/.m2/repository。很多依赖问题的根源都在这里，因为团队往往会统一配置私有仓库地址或镜像地址，而新机器上没设置 settings.xml，IDEA 就会用自己的默认中央仓库去下载，速度慢且容易失败。后面第 4.4 节我给出一个可以复制到本机的 settings.xml 镜像配置。

4.4 依赖自动下载的原理与 settings.xml

IDEA 能自动把 pom.xml 里的依赖全部下载下来，靠的是 Maven 的依赖解析机制。每次读取 pom.xml 时，Maven 会先查本地仓库，如果本地没有就从 settings.xml 配置的远程仓库下载。默认远程仓库是 Maven Central，地址在国外，下载速度不稳定，所以国内团队普遍做法是在 settings.xml 里添加阿里云镜像。以 3.8.x 的 Maven 为例，典型的镜像配置写法如下：

<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>Aliyun Maven Repository</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

这段配置的含义是：当 Maven 需要从 central 仓库拉取依赖时，实际请求转发到阿里云的 public 公共仓库。mirrorOf参数指要镜像哪个仓库，central表示只镜像中央仓库；如果写成*，则镜像所有远程仓库，包括公司私有仓库，这样会导致私有依赖也走阿里云，通常不建议。配置完 settings.xml 后，再回到 IDEA 的 Maven 设置页，把 User settings file 指到这份文件。改完之后想立刻验证，可以打开 Maven 工具窗口点一下 Reload All Maven Projects，底部会出现下载进度条。

依赖解析失败时，本地仓库会生成.lastUpdated结尾的文件，文件名里包含缺失的 jar 坐标，这是判断下载失败原因的第一手资料。下次重新导入前，我习惯先把这些失败文件删掉，否则 Maven 可能会判定“这个包之前下载失败，短期内不再重试”。删除命令用find ~/.m2/repository -name "*.lastUpdated" -delete在 Git Bash 里执行即可。这条命令非常实用，相当于给 Maven 依赖状态清一次缓存，清完再重新加载项目，大概率能解决 60% 以上的依赖缺失问题。

5. 避坑 / 常见问题：我常被问到的拉取与导入问题

5.1 拉取后 IDEA 里看到的不是 Maven 工程

现象是代码明明已经 clone 下来了，文件也都在，但右侧没有 Maven 工具窗口，项目结构里没有 Dependencies，Run/Debug 配置也没有可执行的 Application。原因几乎都是导入时跳过了 external model 选择，或者 Project Structure 里没有把 pom.xml 挂到某个 Module 下。解决方法是右键项目根目录的 pom.xml，选择 Add as Maven Project；如果菜单里没有这一项，说明这个目录还没有被加入模块，需要先 File -> Project Structure -> Modules -> 加号 -> Import Module，再定位到 pom.xml。这个操作做完，Maven 工具窗口才会出现。

还有一种是 IDEA 自动把项目识别成了某种其他类型，比如前端项目或普通文件夹。处理方式是在 Project Structure 里的 Facets 中移除错误类型，再重新关联 pom.xml。这类问题新手容易反复折腾，其实记一句话就行：Maven 工程的识别入口永远是 pom.xml，不是文件夹。

5.2 填错“项目目录”后导致导入失败

现象是导入向导一路 Next，进度条很快走完，但项目里所有的包名都不对，依赖一个都没加载，pom.xml 也没有出现 Maven 的图标。原因是导入向导中填写的路径没有直接包含 pom.xml，IDEA 找不到工程描述文件，只能当成普通目录。解决方法是打开 Maven 工具窗口里的 + 号手动添加模块，或重新走一遍导入流程，这次把路径定位到 pom.xml 所在的目录。注意重新导入时有可能弹出 “Module already exists” 的提示，这时应先从 Modules 列表里删除旧的未完成模块，再重新导入。

为了避免这个问题，我在导入前一定会在文件管理器里打开目标目录，确认里面第一层文件列表就看到 pom.xml，再点下一步。这个习惯帮我省了大量返工时间。尤其是从 Git 拉取出来的仓库里经常带着 CI 脚本、文档、docker 配置等杂项文件，真正的 Maven 工程可能藏在backend/或code/这样的子目录里，不提前看清目录结构，后面每一步都会走歪。

5.3 依赖一直 Downloading 然后报 missing artifact

现象是 IDEA 底部状态栏一直显示 “Downloading...”，过一会儿变成Cannot resolve dependency: xxx:jar:1.0.0。原因分三类：网络访问中央仓库太慢、settings.xml 没有配置镜像、父工程还没有 install 到本地导致子模块引用的 SNAPSHOT 包找不到。第一类和第二类按第 4.4 节的配置就能解决。第三类需要先对父工程执行mvn install，把公共模块 deploy 到本地仓库，子模块才能解析。另外还要注意本地仓库权限，如果~/.m2/repository被设置成只读或者目录里存在.lastUpdated文件，Maven 会卡在同样的报错上。我的排查顺序是：先看本地仓库有没有对应 jar，再看.lastUpdated文件的时间，最后再看 settings.xml 里的 mirror 配置是否生效。

5.4 从 Git 拉取后第一次 push 就报权限错误

现象是 IDEA 里 push 时弹窗报Permission denied (publickey)或Authentication failed。原因一般是 SSH 私钥没有加载到当前会话，或者 HTTPS 的凭据过期。SSH 方式需要在 Git Bash 里执行ssh-add -l看一下私钥列表里有没有内容，如果没有就执行ssh-add ~/.ssh/id_ed25519。如果系统里配了多个 SSH key，还要在~/.ssh/config里明确每个 Host 使用哪个密钥文件，否则 Git 会拿默认密钥去连不同的 GitLab 实例，结果连不上。HTTPS 方式则要在 IDEA 的 Settings -> Version Control -> Git 里配置 Credentials 为 “Use credential helper” 或手动输入 token。Git 使用教程里通常只讲命令，但这些 GUI 里的凭据管理和命令行是两套体系，搞不清楚就会一边能拉一边不能推。

5.5 IDEA 里 Maven 和命令行 Maven 行为不一致

现象是 IDEA 里执行 clean package 全部成功，但打开 Git Bash 执行mvn clean package却报编译错误或测试失败。原因是 IDEA 的 Maven home path 指向了自带的 Maven，而命令行用的是你手动安装的另一个 Maven，两份 settings.xml 不同，本地仓库路径也可能不同。解决方法是让 IDEA 使用和命令行完全相同的 Maven 配置。检查顺序是：Settings -> Build Tools -> Maven -> Maven home path 是否指向你解压的 Maven，而不是 bundled；User settings file 是否指向你配置阿里云镜像的那份 settings.xml；Local repository 是否指向同一个.m2/repository。三个地方保持一致后，两边的行为通常就统一了。如果还有差异，再对比 pom.xml 里是否使用了 Maven 插件版本覆盖，有些插件在本地仓库存在旧版本时不会更新，这种情况与 IDE 无关。

5.6 项目模块识别错乱

现象是导入后 IDEA 的 Project 窗口里出现多个嵌套的同名目录，或者.iml文件生成到了错误的位置。原因是在导入向导里选了错误的目录层级，或者之前的导入残留了缓存。解决方法是关闭项目，删除项目根目录下的.idea目录和所有.iml文件，重新打开。这里的删除操作只是本地工程配置，不影响 Git 代码。删除完后重新走一遍导入流程，IDEA 会重新生成工程描述文件。这个方法对很多莫名其妙的导入问题都有效，我称它为“IDEA 工程缓存后悔药”，操作简单但效果极好。

6. 拉取后必做的三件事：验证工程能编译、能打包、能重构

6.1 先跑通 Maven 的三大周期命令

项目导入完成后，不要急着写代码，先验证它能不能编译、能不能打包。在 IDEA 的 Termial 窗口或系统命令行进入项目根目录，也就是 pom.xml 所在目录，依次执行三条命令：

mvn -N validate mvn clean test-compile mvn package -DskipTests

-N表示只执行根项目，不递归子模块，适合先用它确认聚合工程的父 pom 能被解析。clean test-compile会清除 target 目录并编译主代码和测试代码，这是日常开发中判断代码是否健康最常用的一条命令。最后一条mvn package -DskipTests是打包，其中-DskipTests表示跳过测试执行，但测试代码仍然会编译。这三条命令跑下来，如果全部 BUILD SUCCESS，说明从 Git 拉取到 Maven 导入的整个链路是通的。若某步失败，注意看日志里是编译错误还是依赖解析错误，两种问题的处理方向完全不一样。

6.2 用 Maven 工具窗口和依赖图排查

命令验证通过之后，回到 IDEA 里打开右侧 Maven 工具窗口，检查每个模块的状态。展开 Lifecycle，能正常看到 compile、test、package 等阶段。展开 Dependencies，能直观看到每个依赖是否带红色报错标记。如果某个依赖显示红色，点击后 IDEA 会提示对应的 groupId、artifactId、version，方便对照 pom.xml 里的声明。新版 IDEA 还支持右键 Dependencies -> Analyze Dependencies 打开依赖冲突分析，不过这个功能偏重度，一般排查冲突才用。另外还有一个很实用的点：Maven 工具窗口顶部有个刷新按钮，每次 pom.xml 改动后点一下“Reload All Maven Projects”，比等 Auto-import 自动触发更可靠，尤其是网络不太稳定的时候。

6.3 给新同事的拉取检查清单

我最后总结了一份五分钟检查清单：第一，确认 git、maven、jdk 三个环境变量都配置好了；第二，在 IDEA 的 Get from VCS 里填对 Git 仓库的 clone 地址；第三，Clone 完成之后选择打开项目并进入 Maven 导入向导；第四，向导里填写的项目目录必须直接包含 pom.xml；第五，配置 Maven home、settings.xml、local repository；第六，打开 Maven 工具窗口等依赖加载完成；第七，执行mvn clean test-compile验证能否编译。这七步每步最多一分钟，但能避开我当年走过的所有弯路。以前从 Eclipse 迁过来的时候，我在第一个 Maven 项目上折腾了整整两天，后来才明白拉代码和导工程是两个独立动作，Git 只负责把文件从远程带到本地，IDEA 的 external model 才负责把它变成可以开发的工程。从那以后我每次在新环境下拉项目都强制自己走一遍这条完整的清单，不在任何一个弹窗上凭感觉点按钮，也就再没出过项目无法编译的问题。希望帮到你。

本文还有配套的精品资源，点击获取