如何实现完整历史分支与压缩历史分支的共存Git工作流？

可以实现你想要的工作流，核心是让Git知道main-detailed中哪些提交已经被压缩合并到main了，以下是两种可靠的方案：

方案一：用git reset同步分支基线 #

这个方法简单直接，每次完成一次问题的压缩合并后，把main-detailed重置到main的最新状态，相当于在干净的基线上开始下一个问题的小提交：

• 在main-detailed上完成某个问题的所有小提交
• 切换到main执行：git merge --squash main-detailed，然后提交（提交信息里关联问题ID）
• 切换回main-detailed执行：git reset --hard main
• 接下来在main-detailed上开始下一个问题的小提交即可

这样每次main-detailed的基线都和main保持一致，后续的压缩合并只会包含当前问题的小提交，不会重复处理历史内容。

方案二：用提交标记跟踪已合并内容 #

如果不想重置main-detailed的历史（需要保留所有问题的完整小提交链），可以用标签或者本地标记来记录每次合并后的位置：

• 第一次在main-detailed完成问题A的小提交后，给最后一个小提交打标签：git tag merged/issue-A
• 切换到main执行git merge --squash main-detailed，提交关联问题A的大提交
• 当开始处理问题B时，在main-detailed基于最新的main或者之前的标签继续开发小提交
• 下次合并时，指定只合并标签之后的提交：git merge --squash merged/issue-A..main-detailed
• 完成合并后，更新标签到main-detailed的最新提交：git tag -f merged/last-issue

这种方式可以完整保留main-detailed的所有小提交历史，同时精准控制每次压缩合并的范围。

注意事项 #

• 无论用哪种方案，main-detailed都应该是仅本地使用的分支，不要推送到远程仓库（避免和其他开发者的历史冲突）
• 压缩合并后，main和main-detailed没有共享的提交历史，所以不要用普通的git merge，始终用--squash来处理

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