使用Git将开发分支上的所有更改合并到发布分支

Question

我们使用GitFlow来管理我们的软件仓库：http://nvie.com/posts/a-successful-git-branching-model/ 我有一个情况不确定如何在这个分支模型中处理。

我在几周内向feature分支（从develop分支）提交了约十几个更改。为了减轻合并回develop的负担，我在这两周内将develop的更改合并到了我的feature分支中3次。 feature分支已经完成，并将其更改合并回develop。

然而，事实证明，这个功能也需要在一个距离现在大约一个月前从develop分支派生出来的release分支上。是否有一种方法只合并旧分支中的更改，但省略我3次合并到它的develop的更改？

- Jeff Lamb

---

当你从develop分支拉取内容到你的feature分支时，你执行了实际的合并操作，而不是变基操作？ - Oliver Charlesworth

我理解 release 是在 develop 之后分支出来的，我的理解正确吗？ - jub0bs

我进行了合并操作，但没有进行变基操作。在新的feature分支从develop分支创建之前，Release已经从develop分支创建出来了。 - Jeff Lamb

@Jubobs - 你的巨大回答去哪了，我都没来得及读呢？ - Jeff Lamb

我们正在考虑放弃发布分支并创建一个新的分支来解决这个问题...不过，我会尽快阅读您的方法并进行审查。 - Jeff Lamb

Answer 1

根据Git Flow模型，你错过了这趟列车。

你的仓库应该长这样：

o - o - o - o - o - o [master]
 \
  \       o - o - o - o - o [release]
   \     / 
    o - o - o - o - o - o - o - o - o - o - o [develop]
                 \       \       \         /
                  o - o - o - o - o - o - o [feature]

然而，如果你和你的团队确实遵循Git Flow模型，我有个坏消息告诉你：船已经开了。更具体地说，你不能将feature分支（现在也在develop中）的功能合并到release分支中。这在Git Flow中是不允许的。

如果你看一下nvie.com网站上的下图，你会发现一旦创建了一个release分支，它就不能从develop中接受任何东西，更不要说来自任何功能分支了。release分支的唯一目的是稳定/巩固实际发布，即合并到master分支。

如果你真正坚持Git Flow模型，你应该：

- 放弃当前的release分支，从develop分支的末尾创建一个新的分支， - 或者冻结所有在release上的工作，然后将其重新基于develop分支��继续工作， - 或者等待下一个版本将新功能合并到发布中。

如果你不遵循Git Flow模型...

如果你愿意违背Git Flow模型，你可以将你的功能合并到release中，而不会污染来自develop的最新内容。以下方法的缺点是你的历史记录将有些混乱，并且包含“重复提交”；但如果你真的坚持将feature分支中的功能合并到当前/活动的发布中，我认为你没有其他选择。

为方便起见，假设你的代码库如下所示（我用字母标记了一些提交）：

o - o - o - o - o - o [master]
 \
  \       o - o - o - o - o [release]
   \     / 
    o - A - B - C - o - o - o - o - o - o - o [develop]
                 \       \       \         /
                  D - E - F - G - H - I - J [feature]

你可以做的是：

1. Check out release

   git checkout release
   

2. Get a list of all the revisions that were not merge commits, between commit A and the tip of feature; in this case, that would be commits B, C, D, E, G, I and J. The command

   git rev-list --no-merges A..feature
   

   should do that for you.

3. Pass that list of revisions to cherry-pick in order to apply the changes introduced by those commits on top of release:

   git cherry-pick `git rev-list --no-merges A..feature`
   

   You'll end up with something like this:

   o - o - o - o - o - o [master]
    \
     \         o - o - o - o - o - B'- C'- D'- E'- G'- I'- J' [HEAD=release]
      \       /                                            
       \     /                                             
        o - A - B - C - o - o - o - o - o - o - o [develop]
                     \       \       \         /         
                      D - E - F - G - H - I - J [feature]
   

4. Stabilise the release branch.

5. Once release hits master, you should also merge it into develop, and you should be back on your feet.

- jub0bs

---

是的，我们意识到这是分支模型中的疏忽。然而，Git允许这种情况发生。例如，我可以从我的“feature”分支上“cherrypick”提交到一个新的基于“release”的分支上。然后，在将来自“release”的更改合并回“develop”时，如果有任何冲突，只需从“develop”中获取所有内容即可。我正在尝试找出比这更优雅的方法。 - Jeff Lamb

@JeffLamb 你可能应该等待其他 Stack Overflow 用户的回应并确认这是采取的最佳行动... - jub0bs

对我来说，这个答案是完美的，但如果只有几个提交，那么在第一个“feature”提交中创建一个新分支并挑选除合并提交以外的每个提交可能更容易。然后将此分支合并到发布版。（当然，你会得到重复的提交） - DaniCE

@DaniCE 请参阅修订版8。 我最初的方法与您描述的完全相同，但我认为将这些提交直接应用于“发布”比较简单。 - jub0bs

@JeffLamb 出于好奇，你最终做了什么？ - jub0bs