摘自here
的以下摘录完成的功能和修复在准备发布时会合并回开发分支
据我所知，这意味着当开发人员对自己的工作充满信心时，功能会合并开发。
当需要发布时，会从开发
创建一个发布分支
在这一行中，预计将发布开发分支中的功能。
以上一切都很好，直到某个功能决定不准备好＆＃34;对于QA测试的发布，或者可能几乎是发布日期，所述功能可以移动到下一个版本。
我知道做一个git revert可以帮助解决这个问题。我很久以前就遇到过这种情况（我已经忘记了我在那段时间所做的事情）但是我一直在使用实验性的自定义工作流程来防止这样的情况。
实验性自定义工作流 Worlflow 1
我尝试的流程与gitflow几乎相同，只是部分是＆＃34;功能被合并以开发＆＃34;。在此实验性工作流程中，它被替换为＆＃34;经过验证的要运行的功能被合并以开发＆＃34;
流程变成这样：
它对我来说很好但是有一个小问题。它会在每个rebase上创建重复的提交。我已尝试cherry-pick，merge（使用ff）和pull --rebase，但结果相同。
还有另一种方法，我计划进行测试以避免重复提交每个rebase ，但我认为它还会产生另一组问题。
与上面的工作流程几乎相同
工作流程2
QA发布或测试的所有功能都合并到分支机构，假设预开发
验证功能挑选开发
它并不完美但至少让我的生活变得更加容易。
对此的想法？您是否有更好的替代方案来解决这种情况？
答案 0 :(得分：0)
让我们看看新的变化如何在分支之间移动
常规gitflow：
develop - ＆gt;功能
功能 - ＆gt;开发
develop - ＆gt;释放
工作流程1：
develop - ＆gt;特征
功能 - ＆gt;特征到测试
功能测试 - ＆gt;开发
所以从功能开发到它：
这里我们可以看到带有rebase的重复提交
工作流程2
这看起来很奇怪，我之前没有见过这种方法。它可能有用，我不确定。
但是我认为最好是坚持经典的git流，如果你需要删除功能分支，请使用revert。这些问题的答案也有帮助：