如何基于Git Flow原则回溯构建仅含发布版的Git master分支？

嘿，我太懂你这种情况了——第一次squash合并完美符合预期，第二次看似成功但结果不对，这种落差真的让人头疼。结合你要构建纯发布版本历史master分支的需求，我来帮你梳理问题和修复方案：

常见问题根源 #

你用git merge --squash处理第二个tag时出问题，大概率是因为新master分支和目标tag的历史没有正确关联。Git的merge操作依赖历史上下文，当两个分支没有共同祖先时，merge --squash会把目标tag的所有内容当成“新增变更”，导致最终内容和预期不符。

正确的操作流程 #

要确保每个tag都能作为独立的squashed commit（完整发布状态）出现在新master上，推荐用「内容覆盖+提交」的方式，完全规避历史关联问题：

1. 创建全新的空分支作为新master
   先创建一个没有任何历史的孤儿分支，彻底和原仓库的复杂历史切割：

   git checkout --orphan new-master
   git rm -rf .  # 清空分支里的所有默认内容
   

2. 按时间顺序逐个处理发布tag
   从最早的发布tag开始，依次把每个tag的完整内容同步到新分支并提交：

   • 处理第一个tag（比如v1.0）：

     git checkout v1.0 -- .  # 将v1.0的所有文件复制到当前分支
     git add .
     git commit -m "Release v1.0"
     

   • 处理第二个tag（比如v2.0）：

     git checkout v2.0 -- .  # 覆盖当前分支内容为v2.0的完整状态
     git add .
     # 这里Git会自动识别出相对于上一个发布版本的所有变更
     git commit -m "Release v2.0"
     

   • 后续所有tag都重复上述操作即可。

3. 验证结果
   每提交一个版本后，用diff确认当前分支和对应tag完全一致：

   git diff v2.0 new-master
   

   如果输出为空，说明内容完全匹配。

如果你已经做了错误的合并，怎么修复？ #

如果第二个合并已经完成但内容不对，可以回退到第一个发布版本的commit，然后重新操作：

# 回退到第一个发布commit（假设它的哈希是abc123）
git reset --hard abc123
# 然后按上面的步骤处理第二个tag即可

这种方法的核心是直接基于tag的完整状态构建新分支，不需要依赖原仓库的复杂合并逻辑，能确保每个发布版本在新master上都是干净独立的commit，完全符合你想要的纯发布历史分支需求。

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