Imagine there is a feature branch (let's call it lunch) branched from master. I branch a new branch lunch-pancakes from feature. After committing some code to lunch-pancakes, while someone else commits to lunch we decide to merge the changes. I rebase lunch-pancakes on lunch, merge it and then delete the branch.
Now, the development of pancakes hasn't stopped, and I want to do further changes into the code involving them, so I branch lunch into a new subfeature branch. How should I name it?
lunch-pancakes seems like a really bad idealunch-pancakes-update won't work for long. What do I do, when the situation arises again?lunch-pancakes2 might be acceptable?I don't want to name it after a specific sub-sub-feature (lunch-pancakes-toppings) as I don't know which subsubfeatures, bugfixes and other changes concerning lunch-pancakes are going to be committed to this branch before we decide to merge it into lunch again.
Or is the workflow just plain wrong? How do you handle branch naming in such circumstances?
I have long gone away from naming branches like this. The branches given by my particular workflow are named master, qa and whatever, and always stay that way. The namespace of all other branches is "flat" and equal to their name in my issue tracking system (Jira format, e.g. PROJ-12345, where PROJ is the short project name from Jira). This makes it easy to crossreference (automatically and manually).
As a side point, I never re-use a branch name (i.e. a Jira issue) after that feature branch has merged back into the production code. Think of a feature more as a "development event", not so much as a feature in your application.
Aside from that, there is no official naming convention; git is agnostic of the workflow.