在git-flow模型中，错误会去哪里？

Question

在通常被称为Git-流模型修补程序的特定hotfix-*分支中，小型集成修补程序就在发布之前进入release-*分支。上一版本的通用补丁似乎没有地方。

它们应该出现在哪里？他们应该在自己的bug-*分支中脱离develop (就像feature分支一样)吗？

Answer 1

简单的回答是:是的，用于bug修复的分支(即将发布的版本)应该在特性分支中。如何将特性分支或这些分支命名为bug修复符合您和您的团队的标准，但是如果您遵循Gitflow，则应该对它们进行相同的处理。

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

Gitflow有五种分支类型：master、develop、hotfix分支(以hotfix-为前缀)、发布分支(以release-为前缀)和特性分支。master和develop分支是长期运行的分支，您不直接提交到它们中。release-分支用于为特定版本绘制一条线，然后支持在识别下一个版本和发行版之间修复bug。hotfix-分支专门用于关键的、非周期的生产版本。feature-分支用于为将来的发行版开发单独的特性。

来自使用PRs的环境，除了一个致力于特性分支的开发人员之外，没有任何东西应该直接提交到master、develop或发布分支。这确保每个更改都经过代码检查，同时确保在更改进入之前在CI环境中进行适当的测试覆盖和通过测试。我反对将任何提交直接提交到这些分支中的任何一个，尽管Gitflow本身在将预发布错误修复或更改直接提交到发布分支并将它们拖到开发中并具有特性分支方面没有任何问题。

在您的特定情况下，release-分支不是合适的位置。该软件已经发布，并在master中发布。一旦一个发行版被合并到主版中并在其中进行标记，该特定发行版的发布分支已经超出了它的用途，不需要再存在了。如果你积极地清理你的分支(我认为每个人都应该这么做)，那么这甚至都不是一个选择。

如果您的修补程序不是关键的，那么修补程序分支似乎也不适合。hotfix分支的目的是让某人在不影响正在进行的开发的情况下，非常快地将关键的更改转化为生产。使用这些应该是开发团队的例外，而不是常规。一般来说，关键的修补程序应该是一个例外情况。

唯一剩下的就是一个特征分支。请注意，页面中链接到的有关特性分支的部分。甚至说特性分支“有时被称为主题分支”。如果您的更改针对的是即将发布的任何版本，并且不符合修补程序的标准，那么它应该位于其中一个分支中。

Answer 2

如果它是一个单独的提交，那么只需进行一个识别良好的提交，并将其推到开发分支的顶部，否则创建一个特性分支。

git-flow的作者也发表了一条评论说，您要问的正是：缺失bugfix分支#24。

Answer 3

@Dominik - https://stackoverflow.com/questions/31126132/gitflow-feature-vs-bugfix-branch-naming/31126413#31126413给出了一个有用的答案

Bitbucket有默认的分支前缀，其中包括Bugfix。其思想是，Bugfix可以是开发或发布分支中的任何bug修复，但是Hotfix是特定于要直接应用于master (即生产bug修复)的修补程序的：