6

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.

asked Nov 24, 2016 at 16:11

2 Answers 2

3

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)

answered Nov 24, 2016 at 16:55
1

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

answered Nov 24, 2016 at 16:40

Your Answer

Draft saved
Draft discarded

Sign up or log in

Sign up using Google
Sign up using Email and Password

Post as a guest

Required, but never shown

Post as a guest

Required, but never shown

By clicking "Post Your Answer", you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.