合并分支后Git进程高CPU占用，如何查看其当前执行操作？

我太懂这种焦虑了——刚把bug-fix分支合并到develop，结果Git突然占着CPU不放，还难免想起上次强制退出大文件暂存导致数据丢失的糟心事。咱们一步步来拆解问题，先搞清楚Git在忙什么，再确保数据安全：

一、查看Git当前的执行内容 #

要知道Git在干嘛，得先定位进程再看细节：

• 第一步：找到Git的进程ID（PID）
  • Windows：打开任务管理器，在“详细信息”里找到git.exe进程，记下它的PID。
  • Mac/Linux：打开终端运行top或htop，找到git进程对应的PID。
• 第二步：追踪进程的具体操作
  • 如果你用Mac/Linux，直接在终端运行 strace -p <你的Git进程PID>，这个命令会实时输出Git正在执行的系统调用——比如是不是在遍历大量文件、读写对象库，或者在做垃圾回收（gc）。
  • Windows用户可以用Process Explorer（微软官方工具）：右键Git进程，选“属性”→“线程”，查看线程的栈信息，能看到Git当前在执行的内部操作；或者如果你的Git版本在2.26以上，试试设置环境变量GIT_TRACE2_EVENT=1后重新触发相关操作（如果进程已经在跑，这个方法可能需要配合重启，但能帮你后续排查）。
  • 另外，你也可以观察.git目录的变化：比如.git/index文件的大小是否在波动（索引更新的标志），或者.git/objects目录有没有新文件写入（Git在存储对象）。

二、结合你之前的经历，关键注意事项 #

上次强制退出大文件暂存导致数据丢失的教训得记牢：

• 绝对不要直接强制杀死Git进程（比如用“结束进程树”或者kill -9），尤其是在它处理索引、写入对象库的时候——这很容易破坏仓库的完整性，轻则索引损坏，重则丢失提交记录。
• 先耐心等10-15分钟：如果你的仓库很大，合并后Git可能在后台自动做垃圾回收（git gc）、优化对象库，或者更新索引，这些操作确实会占用不少CPU，尤其是之前有大量文件操作的历史。
• 先备份再动手：如果实在担心，先把整个.git目录复制一份到其他地方，就算后续操作出问题，也能恢复到当前状态。

三、如果Git确实卡住了，安全处理的步骤 #

如果等了很久还是没动静，想终止进程的话：

1. 用温和的方式终止：Linux/Mac运行kill <PID>，Windows在任务管理器选“结束进程”（不要选“结束进程树”）。
2. 检查仓库完整性：运行 git fsck --full，这个命令会扫描整个仓库，找出损坏的对象或缺失的引用。
3. 确认合并状态：运行git status看看工作区和分支的状态，确认合并是否真的完成，有没有未处理的冲突或异常。

内容的提问来源于stack exchange，提问作者NiceStats