时间戳

首页 > 解决方案 > GitFlow如何处理合并开发的取消功能

git - GitFlow如何处理合并开发的取消功能

问题描述

从以下摘录自此处的片段

完成的功能和修复在准备好发布时合并回开发分支

据我了解，这意味着当开发人员对他们的工作充满信心时，功能就会被合并来开发。

当需要发布时，会从开发中创建发布分支

并且在这一行中，预计将发布开发分支中的功能。

以上一切都很好，直到一个功能被 QA 测试确定为尚未“准备好”发布，或者该功能几乎可以移动到下一个版本的发布日期。

我知道做一个git revert可以帮助解决这个问题。我很久以前碰巧遇到过这种情况（虽然我已经忘记了在那段时间我做了什么），但我一直在使用一个实验性的自定义工作流程来防止这种情况。

实验性自定义工作流Worlflow 1

我正在试验的流程几乎与 gitflow 相同，只是部分是“功能合并以开发”。在这个实验性工作流程中，它被替换为“已验证的正在工作的功能被合并以开发”

流程变成这样：

  1. QA 要发布或测试的所有功能都放在（未合并）一个 features-to-test分支（开发分支 + 所有要发布的功能）
  2. 已验证的功能合并开发
  3. 新功能分支是从开发创建的

它对我来说工作正常，但有一个小问题。它在每个变基上创建重复提交。我已经尝试过cherry-pick，merge（使用ff），pull --rebase但结果都是一样的。

我计划测试另一种方法，以避免在每次变基时重复提交，但我认为它也会有另一组问题。

和上面的工作流程差不多

工作流程 2

  1. QA 发布或测试的所有功能都合并到一个分支，比如说预开发

  2. 经过验证的功能被精心挑选开发

  3. 新功能分支是从预开发创建的，因为它包含所有功能（出血边缘）

它并不完美，但它让我的生活更轻松，至少现在是这样。

对此有什么想法？您是否有更好的替代方案来解决这种情况？

标签： gitworkflowgit-flow

解决方案

让我们看看新的变化是如何在分支之间移动的

常规的 gitflow：

  • 开发 -> 功能

  • 功能 -> 开发

  • 开发 -> 发布

工作流程 1：

  • 开发 -> 功能

  • 功能->要测试的功能

  • 功能测试 -> 开发

所以从功能到开发它去：

  • 开发 ->功能->功能测试-> 开发

在这里我们可以看到使用 rebase 的重复提交

工作流程 2

  • 预开发 -> 功能
  • 功能->樱桃采摘->开发

这似乎有点奇怪，我以前从未见过这种方法。它可能会起作用，我不确定。

但是我认为最好的办法是坚持经典的 git 流程，如果您需要删除功能分支，请使用 revert。这些问题的答案也可以提供帮助：

https://softwareengineering.stackexchange.com/questions/295202/what-happens-if-a-feature-merged-into-develop-is-postponed-by-management

Git-Flow 撤消已完成的功能分支

推荐阅读