后继分支的Git命名约定？

Question

想象一下从master分支的一个功能分支（我们称之为lunch）。我从feature分支一个新分支lunch-pancakes。在将一些代码提交到lunch-pancakes后，当其他人提交到lunch时，我们决定合并这些更改。我在lunch上重新编号lunch-pancakes，合并它然后删除分支。

现在，煎饼的发展并没有停止，我想对涉及它们的代码做进一步的修改，所以我将lunch分支到一个新的子功能分支中。我应该如何命名它？

• lunch-pancakes似乎是一个非常糟糕的主意
• lunch-pancakes-update不会长期工作。当情况再次出现时，我该怎么办？
• lunch-pancakes2可能是可以接受的吗？

我不想具体子子功能（lunch-pancakes-toppings）的名字来命名它，因为我不知道哪个subsubfeatures，错误修正和有关lunch-pancakes其他变化会我们之前承诺这个分支做决定再次将它合并到lunch。

或者是工作流程显然是错误的？在这种情况下你如何处理分支命名？

Answer 1

我早已不在这样命名分支。根据我的特定工作流程给出的分支名为master，qa以及其他内容，并且始终保持原样。所有其他分支的命名空间是“扁平的”，并与我的问题跟踪系统中的名称相同（Jira格式，例如PROJ-12345，其中PROJ是Jira中的简短项目名称）。这使得交叉引用（自动和手动）变得容易。

作为一个观点，我从来没有重新使用分支名称（即Jira问题）之后，该功能分支已合并回生产代码。将功能看作是“开发事件”，而不是应用程序中的功能。

除此之外，没有官方的命名约定; git是不确定的工作流程。