Git stash生成的WIP提交为何是合并提交？

先看你执行git log得到的 stash 结构：

*   6088953 (refs/stash) WIP on main: 62c9742 G
|\  
| * 5b46ef8 index on main: 62c9742 G
|/  
* 62c9742 (HEAD -> main) G

你已经清楚index提交对应暂存区修改，这里重点说WIP提交为什么是合并提交：

• 保留完整状态上下文：WIP提交要记录的是「未暂存的工作区修改」，但这些修改不是孤立的——它是基于当前分支HEAD（62c9742 G），同时又叠加在已暂存的index提交之上的状态。用合并提交（把HEAD和index作为两个父节点），能让Git明确这个WIP修改的“依赖基础”，恢复时不会搞错修改的来源层级。

• 清晰区分修改层级：如果把WIP做成独立提交（只以HEAD为父），就没法体现「先暂存了一部分修改，又在工作区做了额外改动」的递进关系。合并提交的结构能直观展示：index是已经暂存的内容，WIP是在index之上的工作区新增改动，两者组合就是你stash时的完整未提交状态。

• 恢复时的精准性：执行git stash apply/pop时，Git会基于这个合并结构，先把index提交的内容恢复到暂存区，再把WIP提交的内容应用到工作区，完美还原你stash前的暂存区+工作区状态。这种方式完全契合Git的提交模型，不需要额外记录状态关联信息，是最简洁的实现方案。

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