Complexity, risk as well as external factors all play a large role in how a particular project decides to branch. Conventions go a long way to simplifying this process and can make projects move smoothly from development to production.
In a nutshell it conventions are:
If a project is named foo then there will be a branch called foo on all git repositories touched by that project.
Branches that match the project name are considered to be stable and "on their way to production".
Using the release superproject is simply a matter of wiring up the branches for a particular project into one branch, which also bears the name of the project.
In practice what this equates to is, after adding the submodules to a superproject, going into the submodule's directory and getting the working directory to match the desired state. If the project branch naming conventions are being followed the content can simply be fetched and then checked out.
If the fetch/checkout process results in a change, at the root of the superproject git status
will reflect the change. The changes can then been commited (on the superproject branch that corresponds to the project name).
These conventions only need to be followed at the by the people who are "interfaces" between teams. The use of Repo Appliances can also aid the branching strategy in that it allows each group to determine what works best for them. For example, development and release engineering (RE) teams have different goals when it comes to managing a codebase. In development a team will be more concerned with how to balance the bugfix and feature streams of a project while RE will focus more on how moving these changes through the various environments affects other projects.