想象一下，有一个功能分支（让我们称之为lunch）从master分支出来。我从lunch-pancakes分支了一个新分支feature。将一些代码提交到lunch-pancakes后，当其他人提交lunch时，我们决定合并更改。我在lunch-pancakes上重新lunch，合并它然后删除分支。
现在，煎饼的开发还没有停止，我想对涉及它们的代码做进一步的更改，所以我将lunch分支到一个新的子功能分支。我该怎么命名呢？
lunch-pancakes似乎是一个非常糟糕的主意lunch-pancakes-update不会长时间工作。当情况再次出现时我该怎么办？lunch-pancakes2可能会被接受吗？我不想在特定的子子功能（lunch-pancakes-toppings）后命名，因为我不知道哪些子提交，错误修正和其他有关lunch-pancakes的更改是在我们决定再次将其合并到lunch之前，将致力于此分支。
或者工作流程是否完全错误？在这种情况下你如何处理分支命名？
答案 0 :(得分：1)
我早已离开这样命名分支。我的特定工作流程给出的分支名称为[ -]?，master等等，并始终保持这种状态。所有其他分支的名称空间都是“平面”，并且与我们的问题跟踪系统中的名称相同（Jira格式，例如qa，其中PROJ-12345是Jira的短项目名称）。这使得交叉引用（自动和手动）变得容易。
作为一个侧面点，在该功能分支合并回生产代码之后，我从不重新使用分支名称（即Jira问题）。将某个功能更多地视为“开发事件”，而不是应用程序中的功能。
除此之外，没有正式的命名惯例; PROJ与工作流程无关。