如何轻松跟踪 git 中多个分支的特定更改？
how to easily track a specific change across multiple branches in git?
先说一下我们软件发布的要求：我们每年要发布2-3次我们软件的新版本。新版本包含新功能。新版本发布后，这个版本需要维护相当长的时间（比如说几年），以防出现bug需要修复。如果出现这样的错误，通常需要在其中几个版本中修复它。但是，不应将新功能移植到这些版本中。
目前，我们使用 bzr 作为我们的 VCS，我们对此并不满意：它有缺陷，速度慢，不受流行的构建服务器支持，并且使用大量磁盘 space（因为每个分支都使用它自己的目录）。
所以我们决定要切换到 git。我们计划了以下分支模型：master 是每个新功能进入的地方（通过功能分支）。每当需要新版本时，都会创建一个新分支（例如 release30）并提供给 QA 进行测试。这些发布分支永远不会合并回 master，也不会相互合并。但是来自 master 的错误修复需要应用于这些分支。挑选这些错误修正已经过测试并满足了这一需求。
但是，我的老板对新的 VCS 有以下（在我看来是非常合理的）要求：对于特定的更改，他想快速轻松地检查在哪些发布分支中应用了此更改，在哪些版本分支中没有应用，这样他就可以快速告诉客户这个特定的错误修正是否包含在这个客户的版本中。最好在 GUI 中单击一下。
对于樱桃采摘，这很困难。我想出了以下想法：
Cherry-picking 将通过 cherry-pick -x 完成，将 cherry-picked 提交的哈希添加到提交消息中。然后可以通过 git log --all --oneline --decorate --grep=<SHA-Hash> 搜索更改。当然，这需要使用命令行。可以使用别名来缩短命令。
问题：
1. 这个问题有没有比我上面贴的更简单的解决方案？
2. Linux 上是否有支持此功能的 GUI？
3. 在这种情况下（多个长期发布分支），您如何跟踪哪些更改包含在何处？
你有没有考虑过"A+successful+Git+branching+model"
我在 Preissel & Stachmann 的 git 书中找到了这个问题的答案（不知道是否有英文版）。
想法：迁移后，我们将每个发布分支与之前的发布分支合并：分支 release/21 上的 git merge -s ours release/20。这样，这些分支被合并而不引入任何来自 release/20.
的更改
然后，如果 release/20 上有错误修复需要包含在 release/21 中，它是分支 release/21 上的简单 git merge release/20。如果有冲突，它们应该是次要的和可管理的。
跟踪现在相当简单：问题 "Is bugfix X in release Y?" 等同于 "Is the bugfix introduced with commit X a predecessor of the commit that branch Y points to?"。这个问题在 GUI 和命令行中都很容易回答。
先说一下我们软件发布的要求：我们每年要发布2-3次我们软件的新版本。新版本包含新功能。新版本发布后，这个版本需要维护相当长的时间（比如说几年），以防出现bug需要修复。如果出现这样的错误，通常需要在其中几个版本中修复它。但是，不应将新功能移植到这些版本中。
目前，我们使用 bzr 作为我们的 VCS，我们对此并不满意：它有缺陷，速度慢，不受流行的构建服务器支持，并且使用大量磁盘 space（因为每个分支都使用它自己的目录）。
所以我们决定要切换到 git。我们计划了以下分支模型：master 是每个新功能进入的地方（通过功能分支）。每当需要新版本时，都会创建一个新分支（例如 release30）并提供给 QA 进行测试。这些发布分支永远不会合并回 master，也不会相互合并。但是来自 master 的错误修复需要应用于这些分支。挑选这些错误修正已经过测试并满足了这一需求。
但是，我的老板对新的 VCS 有以下（在我看来是非常合理的）要求：对于特定的更改，他想快速轻松地检查在哪些发布分支中应用了此更改，在哪些版本分支中没有应用，这样他就可以快速告诉客户这个特定的错误修正是否包含在这个客户的版本中。最好在 GUI 中单击一下。
对于樱桃采摘，这很困难。我想出了以下想法：
Cherry-picking 将通过 cherry-pick -x 完成，将 cherry-picked 提交的哈希添加到提交消息中。然后可以通过 git log --all --oneline --decorate --grep=<SHA-Hash> 搜索更改。当然，这需要使用命令行。可以使用别名来缩短命令。
问题： 1. 这个问题有没有比我上面贴的更简单的解决方案？ 2. Linux 上是否有支持此功能的 GUI？ 3. 在这种情况下（多个长期发布分支），您如何跟踪哪些更改包含在何处？
你有没有考虑过"A+successful+Git+branching+model"
我在 Preissel & Stachmann 的 git 书中找到了这个问题的答案（不知道是否有英文版）。
想法：迁移后，我们将每个发布分支与之前的发布分支合并：分支 release/21 上的 git merge -s ours release/20。这样，这些分支被合并而不引入任何来自 release/20.
然后，如果 release/20 上有错误修复需要包含在 release/21 中，它是分支 release/21 上的简单 git merge release/20。如果有冲突，它们应该是次要的和可管理的。
跟踪现在相当简单：问题 "Is bugfix X in release Y?" 等同于 "Is the bugfix introduced with commit X a predecessor of the commit that branch Y points to?"。这个问题在 GUI 和命令行中都很容易回答。