What is the right process/naming convention with GitFlow to create a subbranch of a feature branch?

Question

I am using GitFlow for my development conventions. Generally speaking, I create a user story and an matching feature branch off my develop branch and work on that. Once the story is complete, the feature is complete and merged (rebased) back into develop.

However, I am now running into the issue where my feature is rather more of an epic. There is some significant amount of development that will be required before the feature (epic) could be delivered (it has to be delivered as a single deliverable). But to work only in 1 feature branch is not appropriate.

That being said, what is the proper convention for doing something like this? Do I create my epic branch called feature/MyEpicName and then just tell all my devs to use feature/MyEpicName as their equivalent "develop" branch? They would then be creating all their feature branches based off that branch, and merging their changes back to that branch.

However, if I follow a process like that, my naming convention starts to get wonky. Normally (by convention), feature/xxxx implies a feature branch from the develop branch. If my devs use the feature/MyEpicName as their "develop" branch, they will still create their own feature/branch. But then it becomes a gargantuan mess to try to understand which feature is branched from develop and which is branched from the epic.

Is there an acceptable naming convention/process to deal with these kinds of situations? Do they call their feature branches feature/MyEpicName/xxxxyyyy?

Will the latter break some of the tooling/scripts? Ex: gitflow hooks, smartgit, etc.

Answer 1

For feature branches we use the convention of feature-name/feature . E.g rewrite-quote/feature as the main feature branch. The keyword feature here is a convention used to signal it as the main feature branch.

Subbranches will be named like feature-name/subbranch name. E.g rewrite-quote/quote-model

The upside of this it is easy to see where each branch belongs. Some tools will even group them together in a folder-like view(sourcetree)

Answer 2

There is no convention for this. Perhaps because long lived feature branches are seen as a Bad Thing(tm)

If this epic is the next version of the software, then the develop branch is the right place for it. its 'sub features' are feature branches, which you create in the usual way and then when they are all done you merge develop into master and do a release.

If you have deliverables which will go live BEFORE the completion of your epic, you would be forced to merge them back into your epic branch, thus delaying its progress while you integrated the changes, retested etc.

I don't believe there is a solution to this situation. You can use feature toggles to switch off unfinished features and then switch them all on when the epic is finished. But this is not ideal, as you will have unfinished work in master.

The best approach in my opinion is to reassess the epic and split it into smaller deliverables that you can complete in your normal release cycle.

For example could you upgrade the database with new tables even if the api layer doesn't use them yet? then the api layer even though its not used by the front end, etc etc