如何借助Git日志生成发布说明，规避cherry-pick的历史混乱问题

方法1：用空合并标记提交已合并（推荐） #

当你在release分支cherry-pick E生成E'后，执行以下命令在release分支添加一个空合并记录，告诉Git和GitHub“E已经被合并到release了”：

# 在release分支执行
git merge --allow-unrelated-histories --no-commit <E的哈希值>
git commit --allow-empty -m "Mark commit [E的简短描述] as merged to release"

这个操作不会修改代码，只是添加一个无代码变更的提交，完全依赖Git原生机制建立E与release的关联。后续用GitHub对比main和release时，会自动识别E已被“合并”，仅显示D和F为待合并提交，无需额外工具或元数据。

方法2：调整合并顺序，提前建立关联 #

如果还未执行cherry-pick，可通过以下步骤避免哈希不一致的问题：

1. 从release分支创建临时分支：git checkout -b temp-release release
2. 将main分支的E提交cherry-pick到临时分支：git cherry-pick E
3. 切回main分支，合并临时分支（保留分支历史）：git merge --no-ff temp-release
4. 最后将main分支合并到release：git checkout release && git merge main
   这种方式会让Git自动建立E与release的历史关联，后续对比时不会误判E为缺失提交。缺点是main分支会引入一条release相关的合并记录，适合不介意main分支包含这类历史的场景。

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