Is there a conventional way to support more than one release in git?

Is there a git workflow designed to maintain software from multiple git branches (e.g., release.1.1
branched from master long ago, and release.1.2 branched from master more recently). Feature Branch
Workflow, Gitflow Workflow, and Forking workflow have great documentation but I haven’t found
information about managing more than one release.

Managing multiple releases would require a process for applying hotfixes and feature to one or more
release branches. A master branch would be used to maintain all changes for future releases, the
release closest to master might get some features and hotfixes, releases furthest would get the fewest
updates, and the release furthest from master would be the first to reach end-of-life.

I’m thinking it would look something like

master -------+----------+----------+----------+------+-----------+--------------------
               \          \          \        /        \         /
                \          \          Hotfix-+          Feature-+
                 \          \                  Hotfix             Feature
                  \          release_1.2-------+------------------+---------------
                   \                             Hotfix
                    release_1.1------------------+----------------------End-Of-Life

The following is revised to look more like Git Flow, but with a ‘release_1.1’ branch.

                                          release_1.1---------+---------+---
                                          |                    \       /
                                          |                     Hotfix3             
                                          |
     tag 1.0     tag 1.0.1     tag 1.1  tag 1.1.1     tag 1.2  tag 1.2.1
       |           |             |        |             |        |
master +-----------+-------------+--------+-------------+--------+------------------
       |          /             /        /             /        /
       |         /             /        /             /        /
       \  Hotfix1             /  Hotfix2             /  Hotfix3        
release |        \       +-+-+          \       +-+-+          \
        |         \     /     \          \     /     \          \
develop +-+--------+---+-------+-+--------+---+-------+----------+------
           \          /           \          /
            FeatureA-+             FeatureB-+

  • Branch history after merging with no fast forward option
  • Merging git repo's and suggested workflow
  • Proper Way To Use Git/GitHub - PHP System with Dev/Testing/Production servers
  • Best practice: Workflow: When to merge in a inhomogeneous team
  • Why is comitting on a detached HEAD allowed at all?
  • View website live after Git push
  • How to prevent broken build in master using gerrit?
  • Mirroring a HG project from Bitbucket to Github
  • One Solution collect form web for “Is there a conventional way to support more than one release in git?”

    You can’t merge a hotfix branch that is based on the current master back into older releases—this would introduce all changes from master into the older release as well. So you have to choose a common ancestor of master and all release branches as the base for your hotfix branch, typically the point where the oldest revision you still want to support diverged from master. From there on, for each release, (1) merge the hotfix branch into the release branch, and then (2) merge the point where the next release diverges from master into the hotfix branch and resolve the conflicts. Finally, merge the hotfix branch back into master.

    You may want to have a look at http://nvie.com/posts/a-successful-git-branching-model/.

    Git Baby is a git and github fan, let's start git clone.