Git 流程题，合并大师开发

Question

我目前正在将 git 流与 sourcetree 一起使用。 sprint 的工作已达成一致，我创建了开发分支以将代码提交到其中。 我将功能分支合并到开发中，然后在冲刺结束时合并到主分支，代码进入生产。

这很好用，但是，如果修复需要推送到 master 或者如果其他工作被购买到 sprint，则需要对提交进行排序并将樱桃挑选到 master 中，这可能会变得非常混乱。

这可能会导致很多阻碍，因为在其他工作可以提交到开发之前，需要将工作推送到主控、测试和签署。

有没有办法安全地引入新工作并致力于开发？

Answer 1

我将功能分支合并到开发中，然后在冲刺结束时合并到主分支，代码进入生产。

如果您愿意，您当然可以这样做，但通常在 Git 流程中，您不会直接将develop合并到master中，因为您遇到的确切问题是：

这可能会导致很多阻碍，因为在其他工作可以提交到开发之前，需要将工作推送到主控、测试和签署。

Git Flow 避免这些问题的方法是使用release和hotfix分支。 （ 详见图表。）

您只需在发布之前创建一个release分支进行测试，因此develop工作永远不必停止。 （请注意，您不必从develop的尖端创建release分支；您可以使用您希望从中分支的任何先前提交。）

当您需要在生产环境中进行修补程序时，您可以从master创建一个hotfix分支。

在您的代码从release或hotfix分支合并到master之后，您还将master合并回develop 。 （或者您可以在将release和hotfix分支合并到 development 之前develop它们合并到master ，但是在将master合并回来之后，恕我直言，它稍微更干净，更容易管理。）

旁注： release和hotfix分支通常是明确定义的，但是，由于您当前在没有它们的情况下工作，您仍然可以在没有它们的情况下工作，但需要进行一些细微的调整。 例如，假设您进行当前的develop并开始在某个地方测试构建，然后您喜欢它并希望将其发布到生产中。 您实际上有一个release分支，但它没有命名。 这只是您测试的提交 ID。 当您发布时，只需将该提交 ID 从develop合并到master而不是develop可能在该提交之前。 这样，您就不会在开始测试后合并到develop中发生的任何新代码。 本质上，这与创建一个专门的release分支相同，但没有实际命名它。 修补程序也是如此。 通常，修补程序是单个提交中的微小更改。 我建议将 master 分支到某个分支，但不必将其称为hotfix ； 任何名字都可以。 然后将该分支 PR 到master并在完成后将master合并回develop ，或者，正如 Git Flow 指出的那样，如果release分支已经存在，则将master合并回release而不是develop （尽管您也可以将release合并回develop如果你想尽快修复）。

旁注：我听到的关于 Git Flow 的最常见抱怨是它过于复杂。 我发现复杂性对于某些组织是绝对必要的，当然对于其他组织则不是必需的。 您可以选择要使用的部分，并在必要时进行调整。 如果您还不需要release分支，那就太好了 - 只需调整您的工作流程，以便在发布时仅将提交 ID 从develop合并到master 。 但是，如果您发现需要针对该提交 ID 进行错误修复，那么您可能可以即时创建release分支。 大多数时候你可以在没有专门的release分支的情况下度过难关。

Answer 2

按照下面的 git-flow 图像：

如果您需要修复一些需要花费大量时间的问题，您可以从 master 那里获得 go 进行开发（如果您有一个快速的任务，例如修复 css，代码样式......）。 在您的情况下，您可以启动一个新功能，完成后您可以使用以下方式进行合并开发：

• git 合并
• git 变基
• git cherry-pick 或使用 git-flow 命令：
• git 流功能完成

我希望这可以帮助你改进你的工作。