使用Git，如果在newfeature分支期间，当我们需要进行热修复时，是否应该创建一个修补程序分支？

Question

看来，让我们说我们已经将所有内容都提交为“1.0版完成”，现在我们想要添加一个功能，最好创建一个分支，比如newfeature，这样当我们需要时“热修复”或“快速修复”，我们可以在master分支和newfeature分支之间切换。

但我确实在一个例子中看到，操作是：

git checkout master
git checkout -b hotfix

// now do any fix that is needed in Emacs

git commit -am "finished hot fix"
git checkout master
git merge hotfix
git branch -d hotfix       // delete the hotfix branch

问题是，是否应创建hotfix并完成hotfix的所有合并和删除？为什么不切换到master分支并进行修复并提交它，就是这样？是否有充分的理由创建hotfix分支？

Answer 1

完全取决于你。

我认为一个好的策略是根据修复的大小来选择。如果一个好的开发人员希望改变一个或两个文件，每个文件中有几行，你可以在主分支上进行。

但是，另一方面，如果有100名开发人员正在进行该项目，并且新的开发人员必须提供可能意味着大量工作的修复，10个以上的文件和100多行需要更改，创建修补程序分支可能更好，更舒适（并删除它是一个好习惯，因为它变得无用甚至打扰）。

决定您是否需要特定分支的标准介于这些案例之间，并且是您（或您的管理员）的决定。

另一种情况是有用的是，如果你同时处理不同的修复/功能并且它们是冲突的（例如配置不同，或者一个不再编译，......）。

Answer 2

如果您使用master分支作为开发分支，我认为无法为修补程序创建另一个分支。但是如果你使用像this这样的分支模型，它非常有用。

他们使用单独的开发和主分支。主分支仅用于标记发布版本。因此，如果您的客户遇到问题并且您想要执行修补程序，则可以从主版本标记创建一个修补程序分支。所以这个修补程序完全脱离了你的正常开发分支，而客户只得到他想要的东西，即修补程序。

合并和删除分支也没问题。如果你正在使用--no-ff你可以重建，那就是合并。

Answer 3

您似乎正在寻找某种git工作流程，我建议git branching model Vincent Driessen称为@nvie以及git-flow所写的工具{{3}}他也是。这真的是一种使用git的优雅方式，你真的需要尝试一下。