在团队协作开发时，经常需要把个人的代码改动合并到主分支。这时候就会用到“合并请求”（Merge Request）。很多人看到有个叫“Squash”的选项，勾了也不知道具体干啥，不勾又怕出问题。其实这个功能挺实用，搞明白能少踩不少坑。
什么是Squash？
Squash翻译过来是“压缩”的意思。在合并请求里，它会把你在当前分支上提交的所有小改动，打包成一个全新的提交，再合并进目标分支。比如你为了修复一个问题，断断续续提交了8次，每次改一两行，日志也写得零零碎碎。如果不开启Squash，这8条记录都会原封不动地进入主分支，看起来特别乱。
而一旦勾选Squash，系统会把这些零散提交合成一条干净的新提交。主分支的历史记录就清爽多了，别人一看就知道“哦，这是修了XX问题”，而不是面对一堆“fix typo”、“wip”这种无意义的提交。
什么时候该用Squash？
举个例子，你在开发一个新功能，过程中反复调试、删改，提交记录可能是这样的：
add user login form
fix style issue in login page
update API call logic
oops, wrong endpoint
revert and fix again
test login with real data
minor text change
final check这些提交对你是有用的，方便回溯过程。但对团队其他人来说，只关心结果：登录功能实现了。这时候用Squash，最终主分支只会看到一条类似“Implement user login functionality”的提交，干净利落。
会不会丢历史信息？
不会。原始的提交记录依然保留在你的分支里，只是合并到主分支的时候被“压平”了。如果你想查中间过程，照样可以点进原来的合并请求页面，看到每一步是怎么改的。相当于把“草稿纸上的演算过程”和“最终答案”分开了。
谁来决定是否Squash？
通常由项目维护者或代码审核人决定。有些团队规定所有合并必须Squash，保持主线整洁；也有些项目希望保留完整开发轨迹，尤其是开源项目。如果你不确定，看看团队之前的合并方式就行。
另外要注意，一旦启用Squash，合并后的提交作者默认是你，但实际提交人会标记为执行合并操作的人。这点在多人协作时要留意，避免归属误会。
和普通合并有啥区别？
普通合并（Merge Commit）会保留所有提交节点，还会自动生成一条“Merge pull request”类的提交，时间线容易变得复杂。Squash则跳过中间环节，直接把改动内容应用过去，像是一次性手动修改后提交。
还有一点，如果用了Squash，后续就不能基于那些被压缩的提交做衍合（rebase）或 cherry-pick 了，因为它们没进主分支。所以如果你的改动可能被其他分支引用，就得慎重。