首先让我告诉您我们软件版本的要求：我们需要每年发布2-3次我们软件的新版本。新版本包含新功能。在发布新版本之后，如果存在需要修复的错误，则需要维护此版本相当长的时间（让我们说几年）。如果发生这样的错误，通常需要在其中几个版本中修复它。但是，新功能不应移植到这些版本中。
目前，我们使用bzr作为我们的VCS，我们对此并不满意：它有缺陷，速度慢，不受流行构建服务器支持并且使用大量磁盘空间（因为每个分支都使用自己的目录）
所以我们决定要切换到git。我们计划了以下分支模型：master是每个新功能进入的地方（通过功能分支）。每当需要新版本时，都会创建一个新分支（例如release30）并将其提供给QA进行测试。这些发布分支永远不会合并回master而不会合并到彼此中。但是master中的错误修正需要应用于这些分支。樱桃采摘这些错误修正程序已经过测试并满足了这一需求。
但是，我的老板对新的VCS有以下（非常合理的imo）要求：对于特定的更改，他希望快速轻松地检查这些更改应用于哪个版本分支，以及它不适用，所以他可以快速告诉客户这个特定的错误修复是否包含在此客户的版本中。最好只需点击一下GUI即可。
采摘樱桃，这很难。我提出了以下想法：
使用cherry-pick -x完成Cherry挑选，将提取的提交的哈希添加到提交消息中。然后可以通过git log --all --oneline --decorate --grep=<SHA-Hash>搜索更改。当然，这需要使用命令行。别名可用于缩短命令。
问题： 1.这个问题比我上面发布的问题更容易解决吗？ 2. Linux上是否有支持此类功能的GUI？ 3.在这种情况下（多个长期释放分支机构），您如何跟踪哪些变化包含在哪里？
答案 0 :(得分：0)
您是否考虑过“A +成功+ Git +分支+模型”
答案 1 :(得分：0)
我在Preissel＆amp; Co.的git书中找到了这个问题的答案。 Stachmann（不知道是否有英文版）。
想法：在迁移之后，我们将每个发布分支与前面的发布分支合并：{/ 1}}在分支发布/ 21上。这样，合并这些分支时不会从release / 20引入任何更改。
然后，如果发布/ 20上有一个需要包含在发布/ 21中的错误修正，那么它在分支发布/ 21上就是一个简单的git merge -s ours release/20。如果存在冲突，它们应该是次要的和可管理的。
跟踪现在非常简单：问题“发布Y中的错误修正X？”等同于“提交X引入的错误修正是分支Y指向的提交的前导吗？”。在GUI和命令行中，这个问题很容易回答。