似乎，假设我们将所有内容都提交为“版本 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分支？
这完全取决于你。
我认为一个好的策略是根据修复的大小进行选择。如果期望一个优秀的开发人员更改一两个文件，每个文件几行，您可以在 master 分支上进行。
但是，另一方面，如果有 100 名开发人员从事该项目，并且新开发人员必须提供可能意味着大量工作的修复程序，10 多个文件和 100 多行要更改，那可能会更好并且更舒适地创建修补程序分支（删除它是一种很好的做法，因为它变得无用甚至令人烦恼）。
决定您是否需要特定分支的标准介于这些情况之间，并且是您（或您的管理员）的决定。
另一种有用的情况是，如果您同时处理不同的修复/功能并且它们是冲突的（例如配置不同，或者不再编译，...）。
如果您使用主分支作为开发分支，我认为创建另一个分支用于修补程序是没有用的。但是如果您使用这样的分支模型，它非常有用。
他们使用单独的开发和主分支。master 分支仅用于标记发布版本。因此，如果您的客户有问题并且您想要进行修补程序，您可以从主发布标签创建一个修补程序分支。因此，该修补程序与您的正常开发分支完全分离，客户只能得到他想要的东西，即修补程序。
合并和删除分支也可以。如果您使用 --no-ff ，您可以重建，有一个合并。
看来您正在寻找某种 git 工作流，我推荐 Vincent Driessen 的git分支模型@nvie以及他编写的工具git-flow 。这确实是一种使用 git 的优雅方式，你真的需要尝试一下。