I'm using GitFlow with feature branches mapped to user stories. Essentially, each feature branch represents a user story. When the story is fully implemented and tested, it is considered done, and the feature is finished (merged back into develop branch).
My issue right now is that my feature has been split into an Epic, with the intent of having a progressive deployment schedule. Each story should be a feature. The vast majority of the stories have been designed such that they do not really have any dependency on each other, to be able to implement them individually. However, the one caveat is that they are all dependent on one common story.
At the moment, the common story (feature) is complete, but hasn't passed the testing/QA department, so I can't merge it back into the develop branch yet. But I want to start work on another story in the epic.
What is the "correct" process at this point? Should I just create a feature branch from the HEAD of my existing feature branch? It doesn't follow the typical GitFlow process, so I was wondering how others have addressed this situation.
Yes, you should create a feature branch from the tip of your existing feature branch. Git Flow, like most processes, is more a set of guidelines than actual rules.
However, if you want a cleaner history, you can have that too. Once the dependent feature branch has been merged into
develop, then check out your new feature branch and do:
git rebase develop
During the rebase, Git will see that the commits from the dependent branch have already been merged to
develop, so they are no longer needed in the feature branch. Thus, your feature branch will now only contain new commits specific to that feature.
If you have pushed it to the server, you'll also have to do:
git push --force-with-lease
Now it will be as if your feature branch came straight off
develop after the dependent feature was merged.