为什么不直接在发布中执行修补程序而不是从master分支？

Question

遵循git-flow模型，我应该在将release和master合并到develop之后删除release分支，并在自己的分支中执行修补程序。我想知道为什么会这样？

与master（和develop合并后保留release分支有什么问题，只需执行develop中的修复并与master合并（和{ {1}}）每当必须在实时系统中进行修复时？

Answer 1

修补程序旨在快速修复需要立即关注的错误，并且不能等到下一个版本实现;因此，推送的代码比其他任何东西都更具紧急性。这就是为什么流程创建一个新的分支，进行必要的更改，推回到主人。

这样做可以防止您在发布或其他分支中进行的任何更改在没有适当的审核周期的情况下提前进入主数据库。

在“维护分支”下的https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow中可以很好地描述：

  

为您的团队提供专门的错误修复开发   在不中断其余工作流程的情况下解决问题   等待下一个发布周期。你可以想到维护   分支作为直接与master一起工作的临时发布分支。

此外，将发布分支合并到主分支时，表示分支中的所有内容都已完成，并且已经过了正确的审核流程。从这个意义上说，在该分支中没有什么可以做的，你可以删除它。当您将其合并到主分支时，代码在某种意义上不再属于发布分支，而是属于它已合并的主分支。