Git流程问题，合并到掌握和开发

如何解决Git流程问题，合并到掌握和开发

我目前正在使用带有 sourcetree 的 git flow。对 sprint 的工作达成一致，我创建了开发分支以提交代码。我将功能分支合并到 develop，然后在 sprint 结束时合并到 master，代码进入生产。

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

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

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

解决方法

按照下面的 git-flow 图像：

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

• git 合并
• git rebase
• git 樱桃挑选 或使用 git-flow 命令：
• git flow 功能完成

希望可以帮助您改进工作。

,

我将功能分支合并到 develop，然后在 sprint 结束时合并到 master 并且代码进入生产。

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

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

Git Flow 避免这些问题的方法是使用 release 和 hotfix 分支。 （See diagram 了解详情。）

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

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

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

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

旁注：我听到的关于 Git Flow 的最常见抱怨是它不必要地复杂。我发现复杂性对于某些组织来说是绝对必要的，而对于其他组织来说当然没有必要。您可以挑选您希望使用的部分，并在必要时进行调整。如果您还不需要 develop 分支，那太好了 - 只需调整您的工作流程，在您发布时将提交 ID 从 release 合并到 develop。但是，如果您发现需要针对该提交 ID 进行错误修复，那么也许您可以即时创建一个 master 分支。这是您在大多数时间无需专门的 release 分支机构就可以解决的问题。