Git rebase 子分支到其他子分支

Question

这可能已经或可能尚未回答，但由于我不知道我想做的确切术语是什么，因此很难通过搜索找到它。

这是我当前的 git 项目布局：

master
  |
  |-branch-a
  |-branch-b
  |-branch-c

我已经意识到在某些情况下，我对所有三个子分支所做的更改都足够相似，因此应该在 master 之上应用它们。但是，master 是我的“导入分支”，我从外部源导入更新的代码，然后将其合并到子分支中。

所以我认为最好的方法是从master 创建一个子分支，比如fixes，然后创建我的子分支：

master
  |
  |-fixes
      |
      |-branch-a
      |-branch-b
      |-branch-c

一旦我这样做了，我将不得不以某种方式消除现有分支与fixes 分支中修复的任何代码的冲突。但我认为困难的部分是将我的子分支重新定位到 fixes 分支，而不会弄乱我的 repo。

值得注意的是，每个子分支都包含需要保持独立于其他分支的代码。基本上在不同的想法上并行发展。一个或多个可能会在稍后合并回master。假设，如果我没有适用于所有子分支的修复，那么fixes 基本上只是master 的镜像。

我该怎么做？

编辑：因为无法在 cmets 中绘制 ASCII，这是对user3236304 的回答的回应。

我想我明白你的意思了。我应该像这样定位我的分支吗？：

master (core fixes go here)
  |
  |-upstream
  |
  |-branch-a
  |-branch-b
  |-branch-c

这样我就可以将我自己的本地核心修复应用到master 并使用upstream 分支跟踪来自上游的更改，并根据需要将它们合并到我的本地分支中？

Answer 1

我会做的略有不同； master 是您常见的集成工作分支 - {a,b,c} 是特定的发布分支，您维护一个特定的“上游”分支，从所述上游导入。

这样做的好处是你有一个特定的区域可以不断地折叠更改，构建新版本 - 期望每个分支-{a,b,c} 可能是衍生（最接近）那个公共分支点。

关于管理公共分支，从它的声音来看，您偶尔会进行合并/樱桃挑选；这很好用，这样的结构可以很容易地偶尔做一个通用的 rebase 来消除噪音/死 CL，最小化实际上游的历史增量。

无论采用何种方法，我建议您退后一步，尝试确定您是否认为您的工作是其他人的真正“大师”（他们会从您那里撤走），或者您是否是某些人的衍生品其他上游。如果您是衍生品，我所描述的效果相当不错；如果您是“大师”，那么您可能会想要一些不同的东西。