Advice on multiple release lines and git-flow, for git non-gurus

Our software product line requires developing and maintaining multiple software versions concurrently. We are relative Git newbies and recently adopted Git Flow to take advantage of Driessen's branching model. We have a very small software team with few dedicated developers (we all wear many hats) and no "integration guru."

Much searching has turned up little specific advice on how to adapt Git and Git Flow to our needs. What has turned up is that Git Flow is not well suited to supporting multiple versions concurrently. One related discussion on SO has answers indicating separate branch names need to be used to track separate versions' histories. This, and related strategies, eliminates Git Flow unless it is modified; see our team limitations above for a reason why this isn't practical for us.

The key question is what have others found to be a good approach for implementing Driessen's branching model as closely as possible while supporting multiple release lines?

UPDATES:

Distilling the answers below (particularly @Rasmus') with more targeted searching and internal discussions on a few options leads to the following solution that we are implementing, and which I offer as one approach that may be relevant to similar teams under similar conditions.

We won't continue to use Git Flow. Instead, we will apply Driessen's model to each individual release line in a repo by prefacing each branch name with its intended release string, e.g.:

r1.5/develop

All versions of a project are contained in the Git repository. Starting a new project version consists of creating a small set of new long-lived branches prefaced by the release string (e.g. r1.6/develop and, in our case, r1.6/release; no master with its implication of the single current good buildable state).

We establish one central public repository per project on a server that will be the main avenue for sharing code through local repo remote links. A push to this repository signifies code that is ready to be consumed by others. Merging RX.Y/develop into and then pushing the RX.Y/release branch signifies code that is intended for release. feature, hotfix, et. al. branches are handled similarly. The branch merge/commit history for a given release line is clean and understandable. We don't want the typical Git distributed repo strategy in favor of avoiding the complexity of merging such repos that, over time, are likely to diverge in structure.

In some Git GUIs (such as SourceTree for example) this branch structure is recognized and displayed as hierarchical, which helps understand the top-level history of a project from the branch structure.

Apologies for not up-voting any answers; my reputation on SO is not yet the minimum required to do so.

we are having a similar setup except we have more than 300 dedicated developers, we have exactly what you described several revision we need to deliver to different customers.

We have divided it so we have an initial ref like refs/heads/platformX.Y/ then we build on that

So depending on what you need to do you checkout platformX.Y/develop and start working from that point on a feature branch and you merge back to develop when you are done.

This works for us and we can follow the nvie model.

on top of everything we are merging all these platformX.Y branch to our main develop branch so errors corrected on those branches are released in to the latest software as well.

Our usual development process fits Driessen's flow workflow well, but we sometimes need to develop a branch with several features for a specialized release, where we don't want the bulk of ongoing development included. We've found a way to do this within flow using existing tools, with just a couple of extra steps. (We are working in mercurial, but the options to git flow and hg flow are the same.)

For example, our next normal release is 23.0, and our special, "sandboxed" release is 22.4.2. For these cases, we:

1. Early on, before the new features are created, create a release branch 22.4.2 for the special release off of develop. It's fine if some features were started earlier as long as they don't come after any work on develop that we want to exclude.
2. Make a tag there for convenience (start-22.4.2)
3. Start each new 22.4.2 feature with start-22.4.2 (a changeset on develop) as it's parent/base. This prevents any work merged to develop in the meantime from leaking onto the release branch. Both the commandline and Sourcetree support choosing a parent besides the tip for git flow feature start.
4. Merge manually from the tip of the 22.4.2 branch to the feature, if desired, and as often as desired, to bring in any completed features from the branch. This lets us deal with any interactions of concern among the new 22.4.2 features on the branch.
5. git flow feature finish the feature, which merges it to develop as normal. (For us, these features are meant to be included in future releases. We're only protecting 22.4.2 from less-tested work.)
6. After finish, we manually merge the last changeset before the close of the feature onto the 22.4.2 branch.