在日常敏捷开发中，版本控制已成为每个研发团队的生命线。但随着项目迭代，许多开发者的版本历史往往充斥着零碎的记录：“修复样式”、“再改一下错别字”、“本地测试临时保存”……这些琐碎琐屑的痕迹，不仅让提交日志变得冗长杂乱，也在日后代码回溯与审查排查时造成了巨大的心智负担。正因如此，合理运用 Squashing 技术进行 Git 合并提交，成为了维护代码仓库健康与整洁的核心手段。
所谓 Squashing，本质上就是将开发过程中产生的多个细微、不完整的 commit 记录，压缩融合成一个逻辑清晰且语义完整的独立提交。在特性分支开发模式下，开发者为了保存工作进度频繁提交是非常自然的习惯。然而在合并进主干分支（如 main 或 develop）时，团队协作更关注的是这次交付到底实现了什么业务价值。通过 Git 合并提交，我们可以将十几条零散的过程记录归纳为一个类似“feat: 新增用户第三方登录模块”的干净节点，对外隐去不必要的试错细节。
这一操作不仅极大地提升了版本库的可读性，更为项目的长期维护构筑了护城河。整洁的提交历史能够显著提升 Code Review 的效率，让审查者把注意力集中在业务逻辑而非琐碎的修修补补上。更重要的是，在后续排查线上故障时，借助 git bisect 快速二分定位或者使用 git revert 安全回滚变动，都依赖于这种具备原子性、不夹杂半截代码的提交历史。
实现 Git 合并提交主要有两种常用途径：
第一种是交互式变基。开发者在特性分支上执行 git rebase -i HEAD~n，随后在弹出的交互编辑器中，保留首个提交的 pick 标记，而将后续需要融合同化的记录前缀修改为 squash（简写为 s）。保存退出后，Git 会提示重新整理并汇整这些提交的说明文字，进而生成全新的线性记录。
第二种方式则更加轻巧快捷，即在主分支上执行 git merge --squash 命令。该操作会直接将目标分支上的所有文件变动整体同步到暂存区，而不自动生成合并节点，此时只需由开发者补上一条规范详尽的提交说明并执行 commit，即可一步到位实现分支特性的整洁归并。
不过，在享受 Squashing 带来整洁历史的同时，也需遵循规范：由于变基操作重写了提交哈希，因此 Git 合并提交应当严格限制在个人本地分支或未公开发布的特性分支上进行，切忌在多人共享协作的公共分支上强推历史；同时，压缩后的单个提交应保持功能完整且自洽，避免把互不相关的修改强行打包，才能让代码历史真正条理清晰。
