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中的任何一个，并询问“ Git如何知道每次合并什么提交”？ 好吧，这是git merge的重要思想之一-git会回过头来意识到已经被合并的内容，并且不会尝试重新合并这些更改。 举例来说，如果合并B ，它是由B1 ， B2和B3 ，然后合并C （其由C1 ， C2 ， C3 + B （ B1 ， B2 ， B3 ）），然后GIT中着眼于合并历史并找到从合并点已经到达的所有提交，找到未到达的提交，然后合并那些无法到达的提交，这就是它知道要合并的内容（在这种情况下，它将是C1 ， C2 ， C3因为发现B1 ， B2 ， B3可达）。 因此，在内部，例如，如果您已经将B合并为A ，然后告诉它将C合并为A ，则git通过执行git rev-list C --not A类的操作来标识未合并的提交，然后合并这些提交。理解这一点的关键是像一个图一样思考它，并意识到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中，然后再汇总它们之间的所有分支，那么您应该重新考虑如何创建分支。 在这种情况下，最好直接从父分支创建分支A到E