有没有一种传统的方法来支持 git 中的多个版本？答案

【问题标题】：Is there a conventional way to support more than one release in git?有没有一种传统的方法来支持 git 中的多个版本？
【发布时间】：2014-06-14 11:52:10
【问题描述】：

是否有一个 git 工作流程旨在维护来自多个 git 分支的软件（例如，release.1.1 很久以前从 master 分支，release.1.2 最近从 master 分支）。功能分支 Workflow、Gitflow Workflow 和 Forking 工作流有很好的文档，但我还没有找到有关管理多个版本的信息。

管理多个版本需要一个将修补程序和功能应用到一个或多个版本的过程发布分支。主分支将用于维护未来版本的所有更改，最接近主版本的版本可能会获得一些功能和修补程序，最远的版本会获得最少的更新，离主版本最远的版本将是第一个达到生命周期结束的版本。

我认为它看起来像

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

以下内容经过修改，看起来更像 Git Flow，但带有一个“release_1.1”分支。

                                          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-+

【问题讨论】：

您是否正在寻找一种标准或建议的方式来管理版本，或者如何为其他分支带来新的更改（修复/功能）？
寻找一种标准或建议的方式来使用 git 管理发布以避免重新发明轮子。
您在问题中提到了 Git Flow。我想知道它如何不足以满足您的需求？它似乎提供了您正在寻找的东西......
比起能支持多发布，能快发布不是更方便吗？如果您对自动化测试有足够的信心，可以在几分钟（或几小时）内随时发布，那么您可能永远不需要同时发布两个版本。
Git Flow 已关闭，但我看不出有人如何在不进行升级的情况下获得修补程序。例如，如果 master 中有一个主要功能需要硬件升级（FeatureB），并且在 FeatureB 中找到了一个主要的安全修复程序（Hotfix3）怎么办。我想知道是否可以返回并为 1.1 版创建一个分支并实施安全修复 (Hotfix3)，并维护该分支直到每个人都有机会升级。

标签： git workflow release-management

【解决方案1】：

您不能将基于当前master 的修补程序分支合并回旧版本中——这会将master 的所有更改也引入旧版本中。因此，您必须选择master 的共同祖先和所有发布分支作为修补程序分支的基础，通常是您仍希望支持的最旧版本与master 不同的点。从那时起，对于每个版本，(1) 将 hotfix 分支合并到 release 分支，然后 (2) 将下一个版本从 master 分歧的点合并到 hotfix 分支并解决冲突。最后，将 hotfix 分支合并回master。

您可能想看看http://nvie.com/posts/a-successful-git-branching-model/。

【讨论】：

这是关于合并的好信息，但没有解决“在 git 中是否有支持多个版本的传统方法？”的问题。但是，在讨论修补程序和合并的主题时，在大多数情况下，实际上没有必要对修补程序使用合并。例如，如果安全漏洞是：print passwords，而修复是if authorized: print passwords，那么实际上不需要合并，可以将此修复放在多个发布分支中。
嗯，您总是可以将修补程序挑选回较旧的修订版 — 但这不是您期望听到的，对吧？我告诉过你用 git 做这件事的最“传统”的方法。是的，这涉及到分支和合并，这不足为奇，因为这可能是 git 的两个最显着的特性。（我知道没有其他 SCM 可以让它们变得如此快速和轻松。）如果您的问题是是否有一个特殊的 git 命令可以做到这一点：不，据我所知，没有。这就是 git 的强大之处：只使用基本命令，您基本上可以做任何您想做的事情。
也许我问的问题不够清楚。网上有很多关于合并、挑选、修补等的信息。但是这个问题与应用程序的 git 存储库的状态有关。如果有用户需要修补程序或想要功能，但无法升级到 master 中的最新标签，是否有用于容纳他们的常规方法。我修改了我的工作流通道以遵循 Gitflow 方法，但使用 release_1.1 分支为无法升级到最新版本的用户提供 Hotfix3。
“如果有用户需要hotfix或者想要一个特性，但是不能升级到master中的最新标签，有没有一种常规的方法来适应他们。” — 当然，这正是我所描述的。
很酷，因此可以从 master 中的标记 x.x.x 创建一个 release_x.x 分支，并使用修补程序和可能的功能保持该分支处于活动状态，直到所有用户都升级到更新的版本。