我目前使用Sourcetree和Git Flow。在确认本次迭代的工作后，我从develop分支创建功能分支来提交代码。我将功能分支合并到develop中，然后在迭代结束时将其合并到master中，代码就进入了生产环境。
这种方法挺好用的，但是如果需要将修复程序推送到master或者其他工作加入到迭代中，那么就需要对提交的代码进行排序和精选，这可能会变得非常混乱。
这会导致很多阻塞，因为需要将工作推送到master，在其他工作可以提交到develop之前进行测试和签名。
有没有一种安全地引入新工作并提交到develop的方法？
develop合并到master，因为您遇到的确切问题正是由此引起的：这可能会导致许多阻塞，因为需要将工作推送到主分支，在其他工作提交到develop之前进行测试和签署。
Git Flow避免这些问题的方法是使用release和hotfix分支。（有关详细信息，请参见图表。）
您只需创建一个release分支进行发布前的测试，因此，在develop上工作永远不需要停止。（请注意，您不必从develop的末端创建release分支；您可以从任何您希望从中创建分支的先前提交开始创建分支。）
当您需要对生产环境进行热修复时，可以从master创建一个hotfix分支。
在您的代码从release或hotfix分支合并到master之后，然后您也会将master合并回develop。（或者您可以在将它们合并到master之前，将release和hotfix分支合并回develop，但在IMHO之后将master合并回来更加清晰和易于管理。）
注意：release和hotfix分支通常是明确定义的，但是如果您目前没有使用它们，仍然可以在进行一些微小调整的情况下使用它们。例如，假设您拿出当前的develop并在某个地方开始测试构建，然后您喜欢它并想将其发布到生产环境中。您实际上有一个release分支，但它没有名称。它只是您测试过的提交ID。当您发布时，只需将该提交ID从develop合并到master而不是合并到可能在提交后进行了任何新代码的develop中。这样，您就不会合并任何新代码。本质上，这与创建专用的release分支相同，但实际上没有命名。热修复也是如此。通常，热修复是单个提交中的较小更改。我建议你从master分支切换到其他分支，但不必称之为hotfix；任何名称都可以。然后，将该分支PR到master中，并在完成后将master合并回develop，或者像Git Flow指出的那样，如果已存在release分支，则将master合并回release而不是develop（尽管如果您希望更快地修复该问题，则也可以将release合并回develop）。
另外注意：我听到的最常见的关于Git Flow的抱怨是它过于复杂。我认为对于某些组织来说，这种复杂性绝对必要，但对于其他组织来说则不必要。您可以自行选择要使用的部分，并在必要时进行调整。如果您还没有需要使用release分支，那太好了-只需调整您的工作流程以将来自develop的提交ID合并到master中即可。但是，如果您发现需要针对该提交ID进行错误修复，那么也许您可以在现场创建一个release分支。这样，您大多数时间都可以没有专用的release分支。根据下面的git-flow图像：
如果您需要修复一些需要很长时间的问题（例如开始一个大型修复，如果您有一个快速任务，如修复CSS，代码样式...），则可以从主分支转到开发分支。 在您的情况下，您可以开始一个新功能，完成后使用以下方法合并到开发分支：
希望这能帮助您改进工作。