iam*_*nph 5 git workflow git-flow
\n\n\n\n\n当完成的功能和修复已准备好发布时，它们会合并回开发分支
\n
据我了解，这意味着当开发人员对自己的工作充满信心时，功能就会被合并以进行开发。
\n\n\n\n\n当需要发布版本时，会从开发中创建发布分支
\n
在这条线上，开发分支中的功能预计将被发布。
\n\n以上一切都很好，直到某个功能被 QA 测试确定尚未“准备好”发布，或者可能快到了该功能可以移至下一个版本的发布日期。
\n\n我知道做一个git revert可以对此有所帮助。我碰巧很久以前就经历过这种情况（不过我已经忘记了那段时间我做了什么），但我一直在使用实验性的自定义工作流程来防止类似的情况发生。
实验性自定义工作流程Worlflow 1
\n\n我正在试验的流程几乎与 gitflow 相同，除了“功能合并以开发”部分之外。在此实验工作流程中，它被替换为“合并待开发的已验证功能”
\n\n流程变成这样：
\n\n它对我来说工作正常，但有一个小问题。它会在每次变基时创建重复的提交。我已经尝试过cherry-pick，merge（与 ff），但pull --rebase结果都是相同的。
我计划测试另一种方法，以避免每次变基时重复提交，但我认为它还会存在另一组问题。
\n\n和上面的工作流程几乎一样
\n\n工作流程2
\n\n所有要发布或由 QA 测试的功能都合并到一个分支，比如说预开发
精心挑选开发经过验证的功能
它并不完美，但它让我的生活变得更轻松，至少现在是这样。
\n\n对此有何想法？您有更好的替代方案来解决这种情况吗？
\n让我们看看新的变化是如何在分支之间移动的
常规 gitflow：
开发->功能
功能->开发
开发->发布
工作流程1：
开发->功能
功能 -> 待测试功能
功能测试 -> 开发
所以从功能到开发它是这样的：
在这里我们可以看到使用 rebase 的重复提交
工作流程2
这看起来有点奇怪，我以前从未见过这种方法。它可能有效，我不确定。
不过我认为最好是坚持经典的 git 流程，如果您需要删除功能分支，请使用恢复。这些问题的答案也可以提供帮助：