Release-please项目中合并提交导致变更日志重复的问题分析

问题背景

在Release-please项目的使用过程中，当Git历史记录包含特性分支的合并提交时，会出现变更日志(Changelog)中重复记录相同变更的问题。这种情况通常发生在开发者使用常规合并(merge commit)而非压缩合并(squash merge)的工作流程中。

问题现象

当Git历史中存在以下两种提交时：

1. 特性分支上的原始提交(如feat: change smth)
2. 合并该特性分支时生成的合并提交(如Merge pull request #178)

Release-please会为这两个提交分别生成变更日志条目，导致相同的变更内容在变更日志中出现两次。例如：

### Features

* change smth (提交哈希1)
* change smth (提交哈希2)

技术原因分析

这个问题源于Release-please处理Git提交历史的方式。该工具会扫描项目历史中的所有提交信息来生成变更日志。当遇到常规合并提交时：

1. 合并提交本身会被解析为一个独立的变更
2. 合并提交中包含的原始特性提交也会被解析
3. 由于两者都包含相同的语义化提交信息(如feat: change smth)，导致工具无法识别它们是描述同一个变更

解决方案建议

Release-please官方推荐使用压缩合并(squash merge)而非常规合并来避免此问题。压缩合并的工作流程具有以下优势：

1. 将整个特性分支的所有变更压缩为单个提交
2. 避免了合并提交的产生
3. 保持了线性的Git历史记录
4. 确保每个变更在变更日志中只出现一次

最佳实践

对于使用Release-please的项目，建议采用以下Git工作流程：

1. 为每个新功能或修复创建独立的分支
2. 开发完成后，通过Pull Request提交变更
3. 使用平台的"压缩并合并"功能而非"创建合并提交"功能
4. 确保压缩后的提交信息遵循语义化提交规范

总结

Release-please工具设计时主要考虑了线性的Git历史记录，对于包含合并提交的非线性历史处理存在局限性。通过采用压缩合并的工作流程，可以避免变更日志重复的问题，同时保持项目历史的清晰和整洁。这一实践不仅解决了当前问题，也符合现代Git工作流的最佳实践。