我正在向我的团队介绍功能驱动开发。我们使用 git，我们刚刚开始为我们的工作创建主题分支。据我了解，应该为每个功能或错误创建一个主题分支，并且这些分支应该是“短暂的”。
我们的工作流程包括为我们发现的每个错误（以及我们想要引入的功能，但暂时不谈）创建一个问题，然后为它创建一个派生自 master 的分支，进行一些更改，提交和推送并跟进然后在代码审查后通过拉取请求合并。
到目前为止，这工作得很好，但是我们遇到了几个错误修复是几行代码的情况（如 2-3）。我指示开发人员创建一个分支，但这似乎有点矫枉过正——即——只为几行代码和一个提交创建一个分支......
在这种情况下最好做什么？只在主分支上进行一些小改动而不是为它们创建一个分支会更好吗？
Git 中的分支非常便宜。创造额外的东西很少会受到伤害。人们不应该觉得有义务制作它们，但这应该是他们的默认设置，他们也不应该因为制作了一个被证明是微不足道的东西而感到愚蠢。
请注意，只要您尚未发布（推送或允许其他人获取）提交，就可以将提交“移动”到分支上。例如，假设你一开始就有这个：
...--A--B--C <-- HEAD -> master, origin/master
然后，您无需先创建分支即可修复某些问题。你做出新的承诺D：
...--A--B--C <-- origin/master
\
D <-- HEAD -> master
但后来你发现这还不够，或者是错误的修复，并决定这应该是一个分支fix-xxx。只需添加一个指向D（使用例如，branch fix-xxx master）的新分支标签，然后设置master为指向回提交C（使用，例如，git reset --hard HEAD~1因为您现在仍在使用master），给出：
...--A--B--C <-- HEAD -> master, origin/master
\
D <-- fix-xxx
现在您可以git checkout fix-xxx将提交D放回工作树并设置HEAD为指向fix-xxx：
...--A--B--C <-- master, origin/master
\
D <-- HEAD -> fix-xxx
一切看起来都好像你fix-xxx先创建了，然后提交了D。
换句话说，这一切都是双向的：随意创建尽可能接近自由的分支，但不要创建它们然后“移动”提交（这里实际上没有任何移动：我们只是洗牌了周围的分支标签！）稍后代替。程序员可以做任何对他们有用的事情。
先创建分支，然后再不需要它的最大优点是，这比不先创建分支，然后再需要它的工作量要少。此外，该步骤非常危险（您必须首先确保工作树是干净的）。git reset --hard
