企业官网建设流程全解析

改模块名这件事，我踩过的坑比想象中多。上周团队里一位同事把order-service这个模块整体改成了trade-service，代码编译一次过，本地跑得好好的，结果提交到 Git 之后 reviewer 直接懵了——diff 里几百个文件全是"删除 + 新增"，历史记录断成了两截，还得挨个去核对哪些是真改动。问题出在哪？他改的是模块名和目录名，但没同步 Maven 的artifactId，也没处理 Git 的大小写与路径追踪。IntelliJ IDEA 里的"改名"从来不是一个动作，而是项目名称、模块名称、根目录名称、包目录名称四条独立的线，每一条背后都挂着一堆配置文件和引用点。这篇就按这四条线拆开讲，说清楚每个名字到底存在哪、用什么方式改最稳、改完之后必须验证什么，尽量让各位一次改对，别在 CI 上才发现问题。

1. 先分清 IDEA 里到底有几种"名字"

1.1 项目名、模块名、目录名、包名，是四条互不相干的线

很多人第一次在 IDEA 里右键目录选 Rename，会以为"改了这个项目就改名了"，这是最典型的误解。IDEA 的命名体系里，至少有四个东西是可以独立存在的。

项目（Project）是 IDEA 打开时最外层的容器，你在窗口标题栏、最近项目列表里看到的那个名字就是它。它的值写在.idea/.name这个纯文本文件里，一行字符串，改起来毫无技术含量，但它跟磁盘上的文件夹名完全解耦——文件夹叫demo-project，项目名显示成我的订单系统，IDEA 是允许的，也不会报任何错。

模块（Module）是 IDEA 真正用来编译、管理依赖和输出路径的单元。一个项目下面可以挂多个模块，模块名决定了编译输出目录（out/production/<模块名>或target/<模块名>-1.0.jar）、决定了 artifact 的默认命名，也决定了 IDE 里那些Run Configuration的Use classpath of module指向谁。Maven 和 Gradle 项目里，模块名本质上是跟着artifactId（或 Gradle 的 project name）走的，IDEA 只是把它读进来显示。

根目录名就是磁盘上那个文件夹的名字，最"物理"的一层。在 Windows 资源管理器按 F2 就能改，跟 IDEA 一点关系都没有。但它会牵动.idea里的相对路径宏$PROJECT_DIR$之外的东西，比如某些 artifact 配置写死了绝对路径，目录一挪就废。

包名和包目录是 Java 世界里最容易被搞混的一对。包名是源码里package com.example.order;这行声明的逻辑名，包目录是磁盘上com/example/order这个物理层级。绝大多数情况下它俩是一致的，但目录不在 source root 下、或者你只改目录不改声明的时候，就会出现"目录叫 a、包声明写着 b"的诡异状态，编译直接报错。

1.2 这些名字分别藏在哪个文件里

把名字的"物理位置"搞清楚，后面所有操作都有据可依。下面这张表是我自己整理过的，每次改名前都会对着扫一遍。

这张表里最值得盯的是"模块名称"那一行，因为它有三套完全不同的实现，Maven、Gradle、纯 IDEA 模块的处理方式差别很大，后面会分节展开。

提示：.idea目录本身是 IDEA 的项目配置文件集合，通常应该是团队共享的核心部分（.name、modules.xml、misc.xml建议入库），而workspace.xml属于个人状态文件，一般会加进.gitignore。改名前先确认这个前提，否则你改的东西别人拉不到。

2. 动手之前必须做的三件准备

2.1 备份.idea与*.iml，而不是备份源码

我见过最惨的一次翻车，是同事改包目录名的时候不小心选了"Rename Directory and Update References"，方向选错，IDEA 把包声明和所有 import 全改了一遍，改到一半机器卡死，回过神来源码已经半残。他本地没提交，最后靠 Git 的git checkout救回来的。

源码有 Git 兜底，但.idea里的东西往往不进版本库，尤其是workspace.xml和artifacts目录。所以改名前，我的习惯是直接把整个.idea文件夹复制一份到项目外，命名成.idea.bak，再把所有*.iml一起复制。整个动作不到十秒钟，但真出问题的时候，把.idea.bak改回.idea、关掉 IDEA 重开，基本能回到改之前的状态，比在 IDE 里一层层撤销靠谱得多。

源码侧也要确认一遍工作区是干净的——git status没有任何未提交改动。理想状态是在一个独立分支上做改名操作，改完验证通过再合并，这样即使中途放弃也不污染主干。

2.2 改根目录名，先关 IDEA 再动文件系统

这个顺序很多人搞反。IDEA 对项目根目录是持有文件句柄的，尤其是在跑着 Gradle Daemon 或者 Maven 进程的时候，这时候在资源管理器里改文件夹名，经常会出现"文件夹被占用无法重命名"，或者更隐蔽的情况——改名成功了，但 IDEA 内部缓存的路径还是旧的，等到你下次同步项目时，它会在旧路径下重新创建一个out目录，然后你会看到两份编译输出，一脸茫然。

正确顺序是：File → Close Project 关闭项目 → 关掉 IDEA 主窗口 → 资源管理器里改文件夹名 → 重开 IDEA → Open 选新目录。如果项目的 Gradle Daemon 还在后台跑，Windows 下最好去任务管理器确认一下java.exe有没有残留，或者干脆用./gradlew --stop先把 daemon 停干净。

这一步还有一个细节值得说：如果你改的是 Maven 项目的根目录名，pom.xml里通常是不需要跟着改的，因为 Maven 的 artifact 名来自<artifactId>，不是目录名。但多模块项目的父 pom 里，<module>标签写的是子模块的相对目录路径，父目录改名不影响这些相对路径，子目录改名才影响。

2.3 用一次全量搜索，把所有旧名字的位置扫出来

在动手改任何东西之前，先做一次全局检索，把旧名字出现的位置列个清单。这一步的价值在于：改名字的时候你是"按清单执行"，而不是"改完一个发现一个"，心态完全不同。

在 IDEA 里按Ctrl + Shift + F打开全局搜索，把旧名字（比如order-service）输进去，范围选Whole project，注意勾选上File mask之外的所有选项，尤其是要包含非源码文件。你会发现这个名字可能出现在下面这些地方：

• pom.xml/build.gradle/settings.gradle里的模块声明与依赖坐标
• .idea/modules.xml、.idea/compiler.xml、.idea/artifacts/下的 XML
• application.yml/application.properties里的spring.application.name
• 日志配置里的 logger 名，比如logging.level.com.example.order=DEBUG
• 单元测试里的@SpringBootTest或硬编码路径
• 前端工程里引用后端接口路径的常量
• README.md、部署脚本、Dockerfile 里的镜像名和容器名

这里有个经验：搜索的时候把旧名字的几种变体都搜一遍。比如模块叫order-service，那还要搜orderService（驼峰形式）、OrderService（首字母大写）、order_service（下划线形式）。很多配置项里用的是驼峰或者下划线，只搜连字符形式会漏掉一堆。

注意：搜索范围要记得把.idea目录包含进去。IDEA 默认的全局搜索会把.idea排除在外，得手动在搜索弹窗的Scope里切到Project and Libraries或者直接关掉"Exclude"过滤。这个坑我踩过一次——代码全改完了，IDEA 打开还是显示旧模块名，找了半天才发现是modules.xml里没改。

3. 改根目录名称的三种路子

3.1 资源管理器直接改名加重开项目：最笨但最稳

这条路子的流程前面提过了，重点在于重开之后要确认几件事。

第一件事看窗口标题栏和 Project 视图的顶层节点。如果顶层显示的还是旧名字，说明.idea/.name没跟着变，需要手动去改。这个文件很小，用任意文本编辑器打开，把内容替换成新名字，保存，然后在 IDEA 里File → Reload All from Disk就能刷新。

第二件事看 SDK 配置。根目录改名之后，.idea/misc.xml里的project-jdk-name一般是安全的，因为它存的是 JDK 的逻辑名（比如17或者corretto-17），不是路径。但如果你的项目用了Project Structure → SDKs里手动指定路径的那种老式配置，重开之后可能会提示 JDK 找不到，这时候去File → Project Structure → SDKs重新指一下路径就行。

第三件事看版本控制。如果项目根目录本身是个 Git 仓库，目录改名对 Git 没有任何影响，因为 Git 记录的是仓库内部相对路径。但如果你的某个子目录里嵌套了独立的 Git 仓库（比如前端放在web/里单独 init 过），改父目录名之后，IDEA 的 VCS 面板可能会显示不出来，需要在Settings → Version Control里重新注册一下根路径。

3.2 在 IDEA 里对目录做 Rename：看着优雅，但有边界

对根目录本身，IDEA 的项目视图里是不显示的（项目节点就是根目录的映射），所以你没法直接右键它选 Rename。能右键 Rename 的，是根目录下面的普通文件夹和包目录。

对普通目录，右键Refactor → Rename（快捷键Shift + F6）之后会弹一个小提示，让你选Rename directory还是Rename directory and update references。这两个的区别非常大：

• 只选Rename directory：磁盘文件夹名变了，代码里的引用路径不变，如果代码里有硬编码这个目录名的字符串，就会失效。
• 选Rename directory and update references：IDEA 会把代码、配置里所有能识别的引用一起改掉，包括import、资源路径、XML 里的引用。这是绝大多数情况下的正确选择。

但要注意，"update references" 不是万能的。它只能识别 IDEA 能理解语义的引用。像application.yml里写的一段字符串order-service，IDEA 并不知道那是个模块名，它只是个普通的 YAML 值，不会被改。所以第 2.3 节的搜索清单还是要照着走一遍。

3.3 项目名和目录名不一致时，谁说了算

有个比较容易困惑的点：项目名改了但目录名没改（或者反过来），到底以谁为准？

答案是各管各的。目录名是文件系统的属性，项目名是.idea/.name的属性。Maven 的<artifactId>又是第三个属性，它决定打包产物的名字。这三个可以在完全不冲突的情况下各不相同。

比如一个很典型的场景：目录叫backend，.idea/.name里写的是交易中台，pom.xml的artifactId是trade-platform。IDEA 打开后，标题栏显示"交易中台"，Project 视图顶层也是"交易中台"，但打出来的 jar 是trade-platform-1.0.0.jar，部署到容器里的应用名也是trade-platform。这三者互不干扰，谁也不报错。

知道了这一点，你就可以有策略地只改你需要改的那一层。很多时候我们想"改项目名"，其实只是想改 IDEA 里显示的那个名字，那就只动.idea/.name就够了，别的都不用碰，风险最低。

4. 改模块名称：三种项目类型三套改法

4.1 Maven 多模块项目里，模块名散落在四个地方

这是最容易漏改的场景。一个 Maven 多模块项目要把order-service改成trade-service，需要同步的地方有这么几处。

第一处，子模块自己的pom.xml里的<artifactId>。这个值决定了打包产物名和 Maven 仓库里的坐标。改完之后，target目录下打出来的 jar 名会从order-service-1.0.0.jar变成trade-service-1.0.0.jar。

第二处，父pom.xml里的<modules>列表。这里写的是子模块目录的相对路径，不是 artifactId，比如：

<modules> <module>trade-service</module> <module>common-utils</module> </modules>

如果你同时改了子模块的目录名，这里必须跟着改；如果只改 artifactId 不改目录名，这里就不动。这是很多人搞混的地方——<module>里填的是路径，不是坐标名。

第三处，其他模块依赖这个模块时写的<dependency>坐标。这个要全局搜，特别是common模块被一堆模块依赖的情况，一处没改就是编译不过。

第四处，如果子模块自己的pom.xml里有<parent>声明，写的是父模块的groupId、artifactId、version。改的是子模块的 artifactId，父模块的坐标一般不动，所以这一处通常安全，但如果你的父子模块命名有联动规则，也要顺手确认。

改完这四处之后，一定要在命令行跑一次mvn -q clean package，不要完全信任 IDEA 的 Maven 面板。命令行跑一遍能暴露很多 IDE 缓存掩盖的问题，尤其是 reactor 构建顺序和多模块依赖解析。

4.2 Gradle 项目：settings.gradle和目录名是绑定的

Gradle 的模块名来自它自己的 project name，而 project name 默认等于目录名。settings.gradle里那一行include就是模块清单：

rootProject.name = 'trade-platform' include 'trade-service' include 'common-utils'

这里的include 'trade-service'对应的是相对目录trade-service/。如果想改模块名但不想动目录，Gradle 提供了显式指定路径和名字的方式：

include 'trade-service' project(':trade-service').projectDir = file('modules/trade-service-impl')

这种写法在"物理目录和逻辑模块名解耦"的场景下很有用，但在小项目里没必要搞这么复杂，直接目录名和模块名统一最省心。

改 Gradle 模块名的时候还有个坑：.idea下面有个gradle.xml和一组.iml文件，IDEA 会为每个 Gradle 模块生成一份。如果你在 IDEA 里改完settings.gradle之后没点同步，modules.xml里的旧模块引用还在，Project 视图里就会出现两个长得差不多的模块节点——一个有效、一个飘红。解决办法是改完配置之后点一下 Gradle 面板左上角的刷新按钮，或者右键Reload Gradle Project。

4.3 纯 IDEA 模块：手动改*.iml和modules.xml

如果你的项目压根没用构建工具，就是 IDEA 自己管编译那种（新建 Project 时选了 "IntelliJ" 作为构建系统），那模块信息就完全由 IDEA 自己维护。

早期的.iml文件里有一个name属性，比如<module type="JAVA_MODULE" version="4" name="order-service">。现在的新版本一般不在属性里存名字了，模块名靠.iml文件名和.idea/modules.xml里的引用共同确定：

<component name="ProjectModuleManager"> <modules> <module fileurl="file://$PROJECT_DIR$/trade-service.iml" filepath="$PROJECT_DIR$/trade-service.iml" /> </modules> </component>

改名的正确流程是：先关 IDEA，把order-service.iml在磁盘上重命名成trade-service.iml，同时编辑modules.xml把这两处路径改掉，再打开 IDEA。如果顺序反了，IDEA 在运行状态下发现iml文件不见了，会在modules.xml里把它标灰，再打开时给你弹一堆"模块找不到"的提示。

顺带提一句，纯 IDEA 项目的模块名还会影响输出路径。Project Structure → Modules → Paths里的Output path默认是out/production/<模块名>，改名之后如果这个路径没跟着变，可能出现"编译成功但找不到 class 文件"的现象，去Project Structure里手动改一下，或者点Inherit project compile output path让它跟着项目走。

这三种情况对照着看会更清楚：

5. 改包目录名称：整篇里最容易改出编译错误的一步

5.1Rename Package和Rename Directory是两个完全不同的动作

在 source root（也就是被标成 Sources Root 的目录，通常是src/main/java）下面，任何一个文件夹右键Refactor → Rename，IDEA 都会先判断这是不是一个包。如果它认为这是个包目录，弹出来的菜单里会有Rename package的选项，同时也会保留Rename directory。

这两个选项的行为差异是致命的：

• Rename package：IDEA 会把磁盘目录改名，同时把该目录下所有.java文件的package声明改掉，并把整个项目里所有相关的import语句更新掉。这是语义级重构。
• Rename directory：只改磁盘目录名。如果这个目录恰好是包目录，那改完之后目录结构和package声明就对不上了，编译必然报错。

如果你点的是Rename package，IDEA 还会在弹窗底部给一个Rename package的路径输入框，以及"更新哪些引用"的勾选列表。这里一定要把Search in comments and strings之类影响面大的选项慎重开启——我有一次改包名，顺手勾了字符串搜索，结果所有配置文件里拼写相似的字符串都被当成引用改了一遍，差点把 JSON 的字段名改掉。包名重构就老老实实只改代码引用。

5.2Compact Middle Packages折叠造成的误操作

这是 IDEA 一个很好用但也很有迷惑性的功能。默认情况下，Project 视图会把com.example.order这种连续的单层目录折叠成一行显示：com.example.order。看起来像"一个包"，实际上磁盘上是三层目录。

折叠状态下右键 Rename，你改的到底是哪一层？答案是最后一层order。想改中间那层example，得先把它展开。展开的方式有两种：点项目视图右上角齿轮图标，取消勾选Compact Middle Packages；或者点一下折叠节点前面的小三角，IDEA 会把它拆成独立层级。

这里有个特别容易被忽略的点：折叠状态下显示的com.example.order，其实 IDEA 把com和example也一并折叠了。如果你要改的是最顶层的com（虽然很少见，但公司并购换域名前缀的时候真的会有这种需求），不展开是改不了的，右键 Rename 只会作用在order上。

提示：如果只是想在 IDE 里看着清爽，完全不想改包名，只是想改包目录的物理层级，那先取消Compact Middle Packages，再用Rename directory逐层改，改完把package声明手动核对一遍。这种方式适合"目录名和包名故意不一致"的特殊场景，但请务必在改完之后跑一次完整的mvn compile验证。

5.3 批量更新后的验证：别只看 IDEA 有没有标红

Rename package执行完之后，IDEA 会做一次增量索引，几秒钟后大部分文件的 import 会更新完毕。但增量索引不等于编译通过，下面这几种情况它查不出来：

• 反射写死的类名。比如Class.forName("com.example.order.OrderHandler")，字符串形式的类名不会被重构识别，代码能编过但在运行时炸。
• MyBatis 的 XML 映射文件。mapper的namespace属性、resultType的全限定类名，这些是 XML 里的字符串，重构不会碰。
• Spring 配置里的包扫描路径。@ComponentScan(basePackages = "com.example.order")这种，注解里的字符串是会被 IDEA 识别一部分的，但application.yml里的type-aliases-package就完全不会。
• 模块化项目的module-info.java。里面的exports com.example.order不会被自动改。
• 测试资源目录里的同名包。src/test/resources/com/example/order/这类路径，IDEA 会把它当普通目录，不会跟源码包绑定重构。

最省事的验证方式是：改完之后直接在项目根目录敲一次完整构建命令（mvn clean test-compile或./gradlew clean compileTestJava），编译能过再看单元测试能不能跑。IDEA 的 Problems 面板有时候会滞后，命令行不给它留任何情面。

6. 名字改了但配置还在喊旧名：一份全局同步清单

6.1 编译输出、Artifact 与部署上下文路径

模块名或 artifactId 一改，打包产物的名字就跟着变，这个变化会顺着往下传到部署环节。如果你是把 war 包丢进 Web 容器里跑的项目，容器的上下文路径默认就是 war 包的文件名。原来访问http://localhost:8080/order-service/api/xxx，war 包改名之后路径就变成了/trade-service/api/xxx，前端那边如果写死了旧路径，接口会直接 404。

同样的逻辑在 Spring Boot 里换成server.servlet.context-path配置项（老版本是server.context-path）。如果这个配置项写死了/order-service，模块改名不会自动改它，得去application.yml里手动同步。

IDEA 自己的 artifact 配置也要看一眼。File → Project Structure → Artifacts里，每个 artifact 有一个名字，还有Output directory。artifact 名字默认跟着模块名生成，模块改名之后旧的 artifact 可能还在，IDEA 会新建一个，结果就是列表里两个 artifact，跑的时候容易选错。建议直接把旧的删掉，只留新的。

6.2 Spring 全家桶里那些硬编码的名字

Spring Boot 项目改模块名的时候，我固定会检查这几个配置项：

spring: application: name: trade-service # 服务注册、链路追踪里的服务名 mybatis-plus: type-aliases-package: com.example.trade.entity mapper-locations: classpath*:mapper/**/*.xml logging: level: com.example.trade: DEBUG

spring.application.name是服务注册中心里的唯一标识，也是日志和链路追踪里用来区分服务的字段，改成新的之后，如果注册中心里还有旧实例没下线，会出现新旧两个实例并存的情况，流量会被分到旧实例上，排查起来特别费劲。稳妥的做法是先把旧实例全部下线、等待注册中心的健康检查周期过一轮，再启动新名字的实例。

type-aliases-package、logging.level前面挂的包名更是重灾区，包名重构的时候这些都是普通字符串，一个都不会被自动改。建议改完之后全局搜一遍旧包名的前缀，逐个确认。

6.3 运行配置与workspace.xml里的路径残留

Run/Debug Configurations里每一条配置都绑定了一个模块，字段叫Use classpath of module。模块改名之后，IDEA 通常会自动更新这个引用，但如果你的workspace.xml是从别处拷过来的、或者项目是从旧版本迁移的，就很容易出现配置仍然指向旧模块的情况，点运行会报Module 'order-service' not found。

workspace.xml是个人配置，一般不入库，所以这个坑通常是"同事能用我不能用"。处理办法很简单：要么去Run/Debug Configurations里手动把模块下拉框重新选一遍，要么在关闭 IDEA 之后直接删掉workspace.xml，重开让它重新生成——代价是丢失窗口布局和最近打开的文件列表，但配置干净。

同一个文件里还存着最近打开的文件路径、断点、版本控制面板的历史。如果项目根目录改过名，这些绝对路径全部失效，IDEA 可能会在启动时提示找不到某些文件。这个无所谓，不是错误，点掉就行。

7. 改完必做的验证链路和两个真实翻车现场

7.1 从 Clean 到 Build 到 Run 的完整验证

改完名字之后，我固定按这个顺序走一遍，大概五分钟，能挡掉九成的问题：

1. 关 IDEA，删掉out和target目录。增量编译的缓存最会骗人，全量重编一次最踏实。
2. 命令行执行完整构建。Maven 用mvn clean package -DskipTests，Gradle 用./gradlew clean build -x test。这一步验证的是构建脚本层面的引用完整性，跟 IDE 无关。
3. 命令行跑单元测试。mvn test或./gradlew test。这一步验证的是包名重构、资源路径、Spring 扫描这些运行时才暴露的问题。
4. 打开 IDEA，让它重新索引。首次打开会花几十秒到几分钟建索引，耐心等进度条走完。
5. 跑一次应用主类。确认启动日志里打印的服务名、包扫描路径、端口都是新的。
6. 检查 git status。看有没有意外的文件删除或新增，尤其是大小写改名的情况，下一节细说。

如果你的项目有 CI，最保险的办法是推一个临时分支上去跑一次流水线。CI 环境是干净的，任何依赖本地缓存的"假通过"都会被戳穿。

7.2 Git 大小写敏感：改名之后文件"凭空消失"

这个坑值得单独拿出来讲，因为它太隐蔽了。假设你把包目录order改成Order，只改了大小写。在 Windows 和 macOS 的默认文件系统上，这是允许的，IDEA 里看起来一切正常。但 Git 默认配置core.ignorecase = true，它认为order和Order是同一个路径，于是：

• 你本地看着文件都在
• 提交之后，git status显示没有变化
• 同事拉下来发现包名还是小写的，或者出现一堆"删除 order 目录、新增 Order 目录"的混乱 diff

处理办法是不要用文件管理器改大小写，而是用 Git 自己的命令：

git mv order Order

git mv会同时操作文件系统和索引，保证 Git 正确记录这次重命名。如果是整个目录树的多层改名，可以先用git mv移到一个临时名字，再移回来：

git mv com/example/order com/example/order_tmp git mv com/example/order_tmp com/example/Order

这个两步走的技巧在 Windows 上特别有用，因为直接改大小写时文件系统不一定会真的执行重命名操作。

7.3 什么时候必须清缓存，什么时候不用

IDEA 的缓存（索引、编译输出、模块依赖图）在改名之后经常是滞后的。判断要不要清缓存，看这几个信号：

• Project 视图里的模块节点飘红，但pom.xml明明是对的
• 代码里明明有 import，编辑区还是标红，提示找不到符号
• 运行配置里选中了正确的模块，还是报Module not found
• 改了包名，索引跑完了有些文件还在用旧包名

出现这些情况，File → Invalidate Caches / Restart，勾上Clear file system cache and Local History，然后重启。重启后会重建索引，通常要等一两分钟。

但也不是所有问题都要清缓存。如果只是某几个文件标红，先去Project Structure → Modules看一眼依赖有没有丢，或者pom.xml有没有被误改。清缓存是最后手段，不是第一反应——我见过有人一遇到标红就清缓存，结果把一个真实的pom.xml语法错误掩盖了半小时，白白浪费一上午。

8. 关于命名，我自己的一些习惯

改名字这件事，做得多了会形成一些下意识的习惯，这里分享几个。

新项目立项的时候就把名字定死，别用demo、test、new-project这种，尤其是公司内部的中间件项目。改名的成本随着项目存活时间呈指数增长——三个月的时候改，二十分钟搞定；三年的时候改，牵扯到部署脚本、监控告警规则、CI 流水线、文档、接入方的配置，可能要排一个迭代。

模块名和目录名保持完全一致。不搞什么目录叫order而 artifactId 叫trade-order-core的花活。一致的收益在于：任何一个人拿到仓库，看一眼目录结构就知道模块名，改的时候也不会漏。Gradle 和 Maven 都支持解耦，但那是给特殊场景留的口子，不是日常该用的姿势。

包名的根前缀用固定的公司域名倒写，从第一天就定好。包名属于那种"改起来动静最大、收益最小"的东西，能不碰就不碰。真需要改，就挑一个业务低峰期，单独拉一个分支，改完让团队所有人停下手上的活同步切换。

改名提交单独成一个 commit，commit message 写清楚"pure rename，无逻辑改动"。这样 reviewer 一看就知道不用逐行读，也方便以后git log --follow追文件历史。如果改名和功能改动混在一个 commit 里，代码评审基本没法做。

最后说一句关于.idea的态度。我的做法是把.name、modules.xml、compiler.xml、misc.xml这些跟项目结构强相关的文件纳入版本控制，workspace.xml、usage.statistics.xml、shelf/这类个人状态目录加进.gitignore。这样做的好处是团队里所有人的模块结构一致，改名的操作可以一个人做完、其他人拉一下就好；坏处是偶尔会有人提交了包含本地路径的配置，需要 review 的时候盯一眼。这个取舍我觉得是值得的，比让每个人自己维护一套模块配置要省事得多。