Github flow relates feature branches to a single product, but there is no reason it couldn't be implemented . Your workflow options depend on how you deploy your application. Consider "MyApp", which has three component services:
MyApp
|- ServiceA
|- ServiceB
|- ServiceC
If you can deploy ServiceA independently of ServiceB and ServiceC, and more importantly deploy all of those independently of code contained by MyApp but which exists in none of the Service* repositories, then just apply Github flow, your preferred workflow, to each repository and team.
If the services are heavily intertwined, and deploying ServiceA necessarily requires a deploy of ServiceB or more importantly, MyApp represents a significant chunk of scaffolding or routing code that has to advance every time one of the Services* repos do, then you might want something like submodules or subtree. In that model, you'd have one Github flow, and an additional step between #4 and #5, namely collecting submodule (or subtree) updates to the services before deployment. I would avoid repository nesting without subtrees or submodules, unless you (and your team) know git extremely well.
All of that written, I'd suggest you take a deep look at your motivations for splitting the application at all. There are advantages to it and successful workflows on it, but they come at a cost: It's more difficult to get a "whole picture" of your history; in certain circumstances it can be harder to debug with tools like git bisect; each new developer has to learn your git infrastructure before he or she can be comfortable working your codebase. These aren't reasons to abandon your plan, just food for thought.
