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.
Answer
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.