Question

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

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

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

我已经意识到，有些情况下，我对所有三个子分支进行的更改都相似，应该在master之上应用。但是，master是我的“导入分支”，我在将其合并到子分支之前从外部源导入更新的代码。

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

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

一旦我这样做，我将不得不以fixes分支中修复的任何代码来解决现有分支的冲突。但我认为困难的部分是将我的子支柱重新定位到fixes分支，而不会弄乱我的回购。

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

我该怎么做呢？

修改：因为我无法在评论中绘制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}可能是衍生的（最接近）共同的分支点。

关于管理公共分支，从它的声音你偶尔合并/樱桃选择;这种方法很好，这样的结构使得偶尔可以很容易地对共同点进行反复消除噪声/死CL，最大限度地减少实际上游的历史增量。

无论采用哪种方法，我建议你退后一步，试着决定你是否认为你的作品对他人来说是真正的“主人”（他们会向你拉扯），或者如果你是某些人的衍生物其他上游。如果你是一个衍生品，我所描述的工作相当合理;如果你是'主人'，那么你可能会想要不同的东西。