GitFlow中如何处理已合并到develop分支的取消特性？

先回顾下你提到的GitFlow核心规则：

完成的功能与修复在准备发布时合并回develop分支
准备发布时，从develop分支创建发布分支

我完全理解你的痛点——当QA测试后发现某个特性还没准备好，或者需要推迟到下一版本时，直接从develop拉取发布分支会把这个“问题特性”带进去，用git revert虽然能解决，但总觉得不够顺畅，所以你尝试了两种自定义工作流，这个务实的思路值得肯定！

关于你的实验性自定义工作流1 #

这个思路把develop定位成“已验证特性的集合”，用features-to-test作为待验证特性的整合分支，逻辑上是通顺的，但你遇到的rebase重复提交问题，本质是因为features-to-test是develop叠加所有待测试特性的“组合分支”：每次把已验证特性合并到develop后，features-to-test再rebasedevelop时，那些已经合并的提交会因为rebase重写历史导致哈希值变化，最终被重复引入。

关于工作流2 #

用pre-develop整合所有待测试特性，再通过git cherry-pick把已验证特性同步到develop，这个方式确实能避免rebase的重复提交问题，但也存在明显隐患：

• cherry-pick相当于复制提交，一旦后续特性在pre-develop上有迭代，develop和pre-develop的提交历史会逐渐分叉，后续合并时容易出现大量冲突
• 从pre-develop拉取新特性分支，虽然能拿到所有前沿特性，但如果pre-develop里存在未验证的bug，会直接影响新特性的开发进度

推荐的优化方案：基于GitFlow的轻量调整 #

其实不用完全重构GitFlow，只需要在发布准备阶段做一点小调整，就能优雅解决你的问题：

方案1：候选发布分支+针对性revert #

1. 当启动发布准备时，先从develop拉取一个release-candidate分支，这个分支专门用于QA测试
2. QA测试后，若发现某个特性需要推迟，直接在release-candidate分支上执行git revert <该特性的提交哈希>，把这个特性从候选分支中移除，完全不用改动develop分支
3. 确认release-candidate没问题后，将它合并到main（或master）做正式发布，同时把合并后的内容同步回develop，确保develop与发布版本一致
4. 被推迟的特性依然留在develop分支中，等下一个发布周期再一起打包测试

方案2：特性开关（Feature Flag） #

如果团队特性迭代频繁，推荐用特性开关的方式从根源解决问题：

• 所有开发完成的特性正常合并到develop，但给每个特性加上开关逻辑，默认处于关闭状态
• 发布前，只打开已经通过QA的特性开关，未通过的保持关闭
• 这种方式完全不需要调整Git工作流，还能支持灰度发布、快速回滚等场景，唯一的代价是需要在代码层面实现开关逻辑

你的两个自定义工作流都是针对痛点的有效尝试，不过推荐优先试试候选发布分支+针对性revert的方案，它对原有GitFlow的改动最小，团队学习成本低；如果团队规模较大、特性迭代节奏快，特性开关会是更长期、更灵活的解决方案。

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