2015-05-27 93 views
0

下面是我们的方案:Git合并分支恢复工作流程

开发人员将Master分叉到新分支并开发一些代码。大师进步。当它通过QA并被合并到Master中时,将执行完整的回归测试。有时候,一个分支(几个被合并/测试的版本)未能回归。所以我们想要恢复合并并继续发布其余的代码。通常情况下,只需要在原始开发中调整一些东西,再次进行QA,然后重新融入主人,但是因为主人最初恢复了原来的变化,所以大部分分支变化都被消除了。如何在修改完成后将此dev分支重新合并到master中而不会丢失由于还原而导致的更改?

+2

为什么你有一个策略首先将一个特性合并到'master'中,当有机会你将不得不恢复和重新合并?解决您的问题的简单方法是停止执行此操作。 –

+0

我同意@TimBiegeleisen在这里 - 而不是合并到master和回归测试中,合并到发布分支或“开发”或类似的东西,回归测试所有东西,在需要的地方进行修复,然后在知道它时最终将*稳定的 –

+0

@scrowler这是我向团队提出的建议,但希望听到有没有更好的方法或技术解决方案。如果您想发布答案,我很乐意接受它。 – BKK

回答

0

git不会合并之前已经合并的任何提交。由于提交仍然在master的历史中(但被后来的提交恢复),git不会再应用它们。该解决方案可以是:

  1. Revert the revert:只需git revert提交该恢复的变化。

或(更好的解决方案):

  • 合并主插入特性分支定期地或当它已准备就绪。
    • 如果所有的测试都通过:很好,将它合并到主(它应该是一个快进)
    • 否则做你需要做的事来解决问题。
  • 1

    在它面对这听起来像您使用的是您的工作流程恢复不正确。

    为了避免这种情况,如果主人超越了分支,你应该将主人合并到分支中而不是其他方式。

    所以:

    • 发展分支。
    • 当开发完成测试和回归测试通过:
      • 合并掌握到分支(不转移到主)
      • 运行回归测试分支
      • 解决任何故障分支
      • 当测试通过:
        • 如果从合并到主人后主人已经改变,冲洗并重复(重新合并主人到分支,重新测试,重新解决)。
        • 否则,合并分支回主(快进)。

    这个工作流程避免了任何需要在任何时候恢复的推广工作流的一部分(开发人员可能仍然需要时间来恢复时间在他们的开发分支)。

    您应该永远不需要将主合并从一个分支恢复到分支,因为对于已经接受到主分支的更改,它们必须在首先到达主分支之前通过了测试。因此,在合并到您的分支后产生的任何失败都需要在该分支中解决,然后才能被接受回主。