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

Question

Our line of software products requires the development and support of several software versions simultaneously. We are new to Git and have recently adopted Git Flow to take advantage of the Driessen branch model . We have a very small team of software developers with several specialized developers (we all wear a lot of hats) and there is no "integration guru".

In most searches, few specific tips have appeared on how to adapt Git and Git Flow to our needs. It turned out that Git Flow is not suitable for simultaneous support of several versions. In one of the related discussions on SO, there are answers indicating that individual branch names should be used to track the history of individual versions. This and related strategies eliminate the Git thread if it is not modified; see our team limitations above for the reason why this is not practical for us.

The key question is what do others consider to be a good approach for introducing the forked Driessen model as much as possible while supporting multiple release lines?

UPDATE:

Redefining the answers below (especially @Rasmus) with a more focused search and internal discussions on several options leads to the next solution that we are implementing, and which I propose as one of the approaches that may be related to similar groups under similar conditions.

We will not continue to use Git Flow. Instead, we apply the Driessen model to each individual release line in the repo, prefixing each branch name with its intended version, for example:

r1.5/develop 

All versions of the project are contained in the Git repository. The launch of the new version of the project consists in creating a small set of new long-lived branches preceded by the release line (for example, r1.6/develop and, in our case, r1.6/release ; no master with its implication of the only valid good building condition).

We install one central public repository for each project on the server, which will become the main means for exchanging codes through local remote repo links. A push to this repository means code that is ready for others to use. Combining RX.Y/develop in and then pushing the RX.Y/release branch means the code intended for release. feature , hotfix , et. and other branches are processed in a similar way. The merge / commit history of a branch for a given release line is clean and straightforward. We don’t want a typical repository strategy with Git to avoid the difficulty of merging repositories that might diverge in structure over time.

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

Sorry for not voting for any answers; my reputation on SO is not yet minimal for this.

Answer 1

We have a similar setup, except that we have more than 300 dedicated developers, we have exactly what you described a few changes that we need to deliver to different customers.

We split it so that we have the original ref, for example refs / heads / platformX.Y /, then we build on this

So, depending on what you need to do, you check the XY platform / develop and start working from this point in the function branch, and you come together again to evolve when you're done.

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

on top of everything that we combine all of these platformX.Y branches into our main development branch, so bug fixes fixed on these branches are also released in the latest software.

Answer 2

Our normal development process is well suited for the Driessen workflow, but sometimes we need to develop a branch with several features for the custom version where we do not want the bulk of the current development to be included. We found a way to do this in a thread using existing tools in just a couple of extra steps. (We work in mercurial, but the git stream and hg stream options are the same.)

For example, our next normal version is 23.0, and our special version with a sandbox is 22.4.2. For these cases, we:

• In the beginning, before creating new functions, create a branch release 22.4.2 for a special release from development. This is normal if some functions were started earlier, if they do not come after any development work that we want to exclude.
• Create a tag for convenience (start-22.4.2)
• Start each new function 22.4.2 with start-22.4.2 (a set of changes during development), since it is the parent / base . This prevents any collaboration to develop at the same time from leaking onto the release branch. Both the command line and Sourcetree support parent selection, except for the hint for git flow feature start .
• Drain manually from the tip of branch 22.4.2 to the function, if necessary, and as often as necessary, to execute any completed functions from the branch. This allows us to consider any interactions of concern among the new 22.4.2 features on the branch.
• git flow feature finish function that combines it to develop as usual. (For us, these features are intended to be included in future releases. We protect only 22.4.2 from less proven work.)
• After finish we manually merge the last set of changes before closing the function on branch 22.4.2.

Answer 3

One solution is to change the gitflow.branch.develop configuration variable. You create a branch in your released version and use this branch as a new development branch. From there you use the usual git -flow commands. If you want to automatically merge this work into the original development branch, change the gitflow.branch.develop variable before the git -flow finish command.