Git 从分支同步分支

Question

假设我从 "A" 的旧标签创建了一个分支 "B"。我对 "B" 进行了一些更改，并针对 "A" 打开了一个拉取请求。然后，我从 "B" 创建一个 "C" 分支，我对其进行更改并打开拉取请求等，直到到达分支 "E".

一旦我完成了对 "E" 的更改，假设所有这些分支仍然有针对 "A" 的未合并拉取请求。由于这些可以按任何顺序合并，并且 "E" 可能对我在 "B" 中的原始更改进行了一些重要更改，我如何确保 "B" 具有 "C, D, E" 中的更改]; "C" 具有 "D, E" 的变化； "D" 具有 "E".

的变化

假设我需要在合并任何拉取请求之前返回并更改 A，但它依赖于 E 的某些更改。

A -----
 \
  B -----
   \
    C -----
     \
      D -----
       \
        E -----

Answer 1

按照你画的方式，C 有所有 B 加一些，D 有所有 C 加一些，E 有所有D 加上一些，所以当你将 E 合并到 A 时，你将 D、C 和 B 全部合并到 A，所以 A 将拥有一切。

如果你说你可以合并B、C、D或E中的任何一个，以任何顺序问"How will Git know what commits to merge each time"？嗯，这是 git 合并的重要想法之一 - git 将返回并了解已经合并的内容，并且不会尝试重新合并这些更改。例如，如果您合并由 B1、B2 和 B3 组成的 B，然后合并 C（由 C1, C2, C3 + B(B1, B2, B3)), 然后 git 看合并历史并找到所有已经从合并点到达的提交并找到未到达的提交并合并那些无法到达的提交 - 这就是它知道要合并什么的方式（在这种情况下，它将是 C1, C2, C3 因为它发现 B1, B2, B3 是可达的）。因此，在内部，例如，如果您已经将 B 合并到 A，然后告诉它将 C 合并到 A，则 git 标识未- merged commits by doing something like git rev-list C --not A and merges those commits.The 理解这一点的关键是像图一样思考它并意识到 git 只是试图找出图的哪些部分从合并点和要合并的分支无法访问，这些是它想要合并的更改。

如果在 B 合并后继续 B（使用 B4），没关系，您只需重新合并分支 B 即可只是从 B 到 A 的新变化，因为它执行我刚才描述的图遍历并意识到 B1、B2 和 B3 已经合并，现在它只是需要合并的这个新 B4。

Answer 2

从父分支创建的分支的典型生命周期是，前者最终会在某个时刻合并回父分支。这个概念不限于 Git，而是一般的开发工作流程。

在你的情况下，如果你遵循这个原则，它会立即解决你的问题。这是您的图表，重新绘制后更可口：

A -----
 \
  B -----
   \
    C -----
     \
      D -----
       \
        E -----

按照分支合并回父级的原则，合并的顺序应该是E到D，D到C，C变成B，最后B变成A。在这些合并中的每一个中，理想情况下都不应存在冲突。如果存在冲突，它们不应该是由于父级和分支相互踩在脚趾上，即两个分支在功能的相同区域上工作。

如果您的开发过程可能要求您需要将 E 中的更改引入 A before 汇总其间的所有分支，那么您应该重新考虑如何创建分支。在这种情况下，您最好直接从父分支创建分支 A 到 E。

Git 从分支同步分支

Git syncing branches from branches

git

git-merge