git-flow模型中的错误修正在哪里？

在通常称为Git-flow模型的修补程序中，修补程序进入其特定hotfix-*分支，而在发布之前的小型集成修补程序也进入该release-*分支。以前版本中的常规错误修正似乎没有位置。

它们应该出现在哪里？它们是否应该在自己的bug-*分支中分支develop（就像feature分支一样）？

git gitflow

— 鞋子
source

为什么已发布代码中的非关键错误与小功能会有所不同，从而产生与应用程序当前不同的行为？

— Bart van Ingen Schenau，2016年

@BartvanIngenSchenau您是否建议他们成为feature-*分支机构？可以将对错误行为的修复视为一项功能？

— 鞋

@Shoe我认为Bart的意思是您应该将它们视为功能，而不必使用相同的branch prefix。

— Darkhogg

@Shoe：在git的流量，除任何一间分行master，develop，release-*或者hotfix-*是一个特性分支，所以你可以使用像任何前缀，你并使用不同的前缀错误。另外，按规定工作的错误行为与偏离规范的错误行为有什么区别？在这两种情况下，这都是错误的行为，但是只有最后一个是错误。

— Bart van Ingen Schenau，2016年

简短的答案：是的，计划在即将发布的版本中进行错误修复的分支应该位于功能分支中。如何命名功能分支或这些分支以进行错误修复取决于您和您团队的标准，但是如果您遵循Gitflow，则应将它们等同对待。

Bart van Ingen Schenau的评论提出了一个很好的观点。

Gitflow有五个分支类型：master，develop，修补程序分支（前缀hotfix-），发布分支（前缀release-和功能分支的。master和develop分支长期分支和你没有直接提交到他们。release-分支是由画一条线特定版本，然后在下一个版本的标识与版本之间提供错误修复。这些hotfix-分支专门用于重要的非周期版本投入生产；这些feature-分支用于为某些将来的版本开发单个功能。

从那里永久居民的使用和除了个别开发商承诺一个特性分支的环境中来了，没有什么应致力于直接进入master，develop或发布分支。这样可以确保对每个更改进行代码审查，并确保在更改进行之前确保适当的测试覆盖率并在CI环境中通过测试。我反对直接对这些分支之一进行任何提交，尽管看起来Gitflow本身并没有这样做。将预发布的错误修复或更改直接提交到发行分支，然后将其引入开发，然后引入功能分支，将不会有任何问题。

在您的特定情况下，release-分支机构不合适。该软件已经发布并且在中master。一旦将某个发行版合并到master并在其中进行标记，该特定发行版的release分支便已失效，并且不再需要存在。如果您积极清理分支机构（我认为每个人都应该这样做），那么这甚至不是一个选择。

如果您的修补程序不是很关键，那么修补程序分支似乎也不适合。修补程序分支的目的是让某人非常快速地对生产进行关键更改，而不会干扰正在进行的开发。使用这些应该是例外，而不是开发团队的规范。通常，关键修补程序应该是例外情况。

剩下的唯一一件事就是功能分支。请注意，在有关功能分支的问题中链接到的页面部分甚至说功能分支是“有时称为主题分支”。如果您的更改以任何即将发布的版本为目标，并且不符合修补程序的条件，则更改应位于这些分支之一中。

— 托马斯·欧文斯
source

我们同意不应直接承诺掌握，开发或发布分支。但是，当您在发行分支中发现错误时，PR流程应该是什么，并且需要在发行和开发分支中都将其修复。如果您还没有准备好将整个发行分支合并到开发环境中，那么这将是一个挑战，但是应该在两个地方都进行错误修复。如果您愿意，我可以对此发布新的问题。

— 闷棍

@Sap一个新问题会很好，但是如果您发布它，请解释为什么此修复程序如此关键，需要将其合并到两者中-似乎暗示在引入此问题之前没有发现关键问题develop，不是在引入它与创建release分支之间找到的，和/或您的release分支存在了很长时间。但是，简单地说，我相信唯一的选择是选择问题（我建议将修复和请求请求发布到发布分支中，合并到发布分支中，然后通过请求请求将选择樱桃发布到开发中）。

— Thomas Owens

如果是单个提交，则只需进行一个确定良好的提交并将其推送到开发分支的顶部，否则创建一个功能分支。

git-flow作者还发表了一条评论，确切地说出您要问的问题：缺少错误修正分支＃24

— 德比
source

谢谢，您分享的链接为我清除了此问题。

— arcseldon