遇到 Git 合并报 128 错误码，通常不是普通的代码冲突，而是仓库状态或环境权限出了问题，优先检查锁文件和工作目录权限。

命令速用版

# 检查是否有锁文件 (Linux/macOS)
ls -la .git/index.lock
# 检查是否有锁文件 (Windows PowerShell)
Test-Path .git\index.lock

# 查看仓库当前状态
git status

# 检查仓库完整性
git fsck `--full`

为什么会这样

在 Git 的退出码规范中，1 通常代表操作未完成但可恢复（如普通合并冲突），而 128 代表致命错误（Fatal Error）。当合并过程返回 128 时，往往意味着 Git 无法写入索引文件、仓库对象损坏或当前目录权限不足，而不是简单的代码内容冲突。经验表明锁文件残留和磁盘空间问题是常见诱因。

分步处理

第一步：清理锁文件

如果进程意外中断，.git/index.lock 可能未被删除。务必先确认没有其它 Git 进程正在运行，否则强制删除可能导致数据损坏。确认安全后，手动删除该文件。

# Linux/macOS
rm -f .git/index.lock

# Windows PowerShell
Remove-Item .git\index.lock

# Windows CMD
del .git\index.lock

第二步：检查磁盘与权限

确认磁盘空间未满，且当前用户对仓库目录有读写权限。权限不足会导致无法写入新索引。

# 检查磁盘空间 (Linux/macOS)
df -h .
# 检查磁盘空间 (Windows PowerShell)
Get-PSDrive -PSProvider FileSystem

# 检查目录权限 (Linux/macOS)
ls -ld .git
# 检查目录权限 (Windows)
dir .git

第三步：验证仓库完整性

使用 fsck 检查对象是否损坏。如果有损坏，尝试从远程重新 fetch 或克隆。

git fsck `--full`

怎么验证是否生效

执行 git status 命令，观察是否能正常输出分支信息且无报错。随后再次尝试合并操作，检查退出码。

# Linux/macOS Bash
git merge <branch-name>
echo $?

# Windows PowerShell
git merge <branch-name>
echo $LASTEXITCODE

若输出为 0 表示成功，1 表示有普通冲突需解决，若仍为 128 则说明底层问题未解决。

常见坑

• 不要直接在报错时强制提交，可能掩盖仓库损坏问题
• 删除 lock 文件前务必确认没有其它 Git 进程正在运行
• 若在 CI/CD 环境中遇到，检查容器磁盘空间是否已满
• Windows 用户注意路径分隔符使用反斜杠 \

参考来源

• Git 官方文档 - git-scm.com/docs/git
• Git 源码中关于退出码的定义（die() 函数返回 128）