goland 重命名文件不会修改 git 历史，但启用“enable renaming files via vcs”后可触发 git mv，使下次提交记录为重命名而非删增，从而保留 blame、log --follow 和合并上下文。
GoLand 本身不会、也不能在重命名文件时自动更新 Git 历史记录——Git 历史是只读的快照链，重命名操作不会“改写”过去提交中的文件名。但你可以让 GoLand 在重命名时触发 Git 的 git mv 行为，从而在**下一次提交中保留重命名语义（而非删除+新增）**，这是真正影响后续 git log -p、git blame 和分支合并行为的关键。
GoLand 重命名文件时默认走的是 IDE 重命名，不是 git mv
当你右键一个 Go 文件 → Refactor → Rename，GoLand 默认执行的是纯 IDE 层面的重命名：它修改文件名、更新 import 路径、调整引用，但底层调用的是 mv 系统命令，而不是 git mv。这会导致：
- Git 认为这是「删除旧文件 + 新增同内容文件」，
git status显示两行：deleted: old_name.go和new file: new_name.go -
git blame new_name.go查不到旧文件里的历史提交 - 如果旧文件里有未合并的分支变更，重命名后可能丢失上下文关联
必须手动启用「Rename file via VCS」选项
要让 GoLand 在重命名时走 Git 流程，需提前开启该开关：
- 打开
Settings → Version Control → Git（Windows/Linux）或Preferences → Version Control → Git（macOS） - 勾选 Enable renaming files via VCS（注意：不是“Rename files in VCS”，后者是另一功能）
- 重启 GoLand 或重新加载项目使设置生效
启用后，再次右键 → Refactor → Rename，IDE 底部状态栏会显示 Renaming via Git...，且 git status 将正确显示 renamed: old_name.go -> new_name.go。
重命名后 Git 历史不会“自动更新”，但后续操作可继承上下文
即使启用了 Enable renaming files via VCS，Git 也不会回溯修改已有提交。但它确保了：
- 当前工作区的重命名被记录为 atomic rename 操作
-
git log --follow -p new_name.go能完整追溯到old_name.go的全部历史（包括 commit hash、作者、时间） - 执行
git merge或git rebase时，Git 能基于文件内容相似度自动识别 rename 关系，避免误判为冲突或丢失 patch - 如果你之后运行
git rerere，它也能把 rename 后的冲突解决方案与原路径绑定
容易被忽略的边界情况
这个机制对以下场景无效或需额外处理：
- 批量重命名多个文件时，GoLand 可能只对第一个文件触发
git mv，其余仍走普通mv—— 建议单个操作，或改用终端执行git mv old1.go new1.go && git mv old2.go new2.go - 重命名发生在未跟踪的文件上（untracked），
git mv会失败；此时需先git add再重命名，或手动git add -N new_name.go - GoLand 的
Refactor → Move（移动到其他目录）同样依赖该开关，但跨 module 移动可能触发 go.mod 依赖检查中断，需手动验证go list -m all
真正的“历史更新”只发生在你提交那一刻；之前所有操作都是为那次提交准备正确的元数据。别指望 IDE 替你改写过去，但可以确保未来每一次 git log 都不让你抓瞎。
