我们的团队正在使用git flow，我们每两个月就会持续发布一次。关于何时应该创建发布分支，我有点困惑。
例如在下面的例子中，在最后一个版本中有一个错误，应该在这个版本中修复，如果我首先创建发布分支并从发布分支创建bugfix分支或者只是从开发创建，执行所有功能开发和合并回来开发，然后从开发创建发布分支？
我是否应该推送小错误直接发布分支而不创建bugfix分支？
我是否应该将来自功能分支或bugfix分支的开发中的一个提交合并到发布分支？
答案 0 :(得分：3)
通常，发布分支从develop分支分支。在发布分支上，版本增加，然后它合并到主分支。在将release分支合并到master分支并返回到develop分支之后，您还应该从master分支创建一个Tag，并根据先前发布的版本的verison编号命名。
例如在下面的例子中，在最后一个版本中有一个错误，应该在这个版本中修复，如果我首先创建发布分支并从发布分支创建bugfix分支或者只是从开发创建，执行所有功能开发和合并回来开发，然后从开发创建发布分支？
在这种情况下，您将为该bug创建一个功能或错误修复分支，修复它并将其合并到develop中。之后，您将完成所有功能开发，并在准备发布后立即从开发分支创建发布分支，然后按上述步骤继续。
我是否应该推送小错误直接发布分支而不创建bugfix分支？
您不应该在发布分支上进行开发，而应该在开发分支上进行开发。在将其合并到master并开发之后可以删除release分支，然后在发布下一个版本时再次创建它。
我是否应该将来自功能分支或bugfix分支的开发中的一个提交合并到发布分支？
如果要发布仅包含1个功能或1个错误修正的新版本，只需从开发分支创建新版本分支，然后按照上述步骤创建发布。没有理由不这样做（即如果你想创建一个只包含1个bugfix的bugfix版本）......
有关GitFlow的更多详细信息，请参阅here
答案 1 :(得分：0)
因此，如果您大约每两个月进行一次连续发布，那么我建议您开始在主要的Development分支中开始下一个版本（1.0）的开发工作。一旦按照版本（1.0）的承诺完成了开发，请削减版本分支并将其部署到您的暂存/预生产/ QA环境中。在测试您的发行版（1.0）时，您可以让您的开发人员在下一个发行版（1.x或2.x）的主要开发分支上工作。因此这不会停止您的开发。现在，如果质量检查人员在release（1.0）中发现缺陷，那么请开发人员在主要开发分支上对其进行修复，然后您可以选择该特定修复程序并将其与release（1.0）分支合并。对于测试期间质量检查发现的所有缺陷，请遵循此方法。一旦release（1.0）被成功测试并签名，将其部署到PROD并将其合并到master分支。
问题1：如果最后一个版本中存在错误，并且应该在此版本中修复，我应该首先创建release分支并从release分支中创建bugfix分支，还是仅通过development创建它，请进行所有功能开发并合并回开发，然后从开发创建发布分支？ 答：如果在开发人员仍在为发行版（1.x）进行编码的同时在发行版（1.0）中发现PROD错误，请将该代码进行编码并在1.x中修复，作为用户故事的其他功能。在已经从主开发中删除了release分支（1.x）之后的release（1.0）中，则有两个选择。 A）如果这是一个紧急问题，则从master创建一个修补程序分支，使其在非产品环境中进行修复和测试，然后将其部署到PROD。由于它的修补程序很紧急，因此在测试修补程序时，所有测试和常规发行版（1.x）的其他活动都必须暂停。 B）如果不是修补程序，请按照我为上述缺陷说明的相同方法进行操作。这意味着将其分配给开发人员，然后让他修复该错误并检入主开发分支。然后樱桃选择更改并将其合并到release（1.x）分支中，并对其进行测试，然后将其部署到PROD。 >
问题：是否应该在不创建bugfix分支的情况下直接推送一些小错误以直接释放分支？ 答：您可以跳过bugfix分支，但是这完全取决于时间。如果问题很紧急，那么您必须从master创建一个bugfix / hotfix分支，以便可以对其进行快速测试和部署。从master创建分支将确保未经测试且与修补程序无关的代码不会与修补程序一起部署。如果问题不紧急，则可以通过发布分支本身进行处理。
问题：我是否应该将来自development（来自功能分支或bugfix分支）的单个提交合并到release分支？ 答：当然，这就是所谓的“樱桃采摘”，包括谷歌团队在内，我们都可以做到。