使用Git将所有更改从开发中的功能分支合并到发布分支

Question

我们使用GitFlow来管理我们的软件存储库： http ：//nvie.com/posts/a-successful-git-branching-model/

我有一种情况，我不知道如何处理这个分支模型。

在几周的时间里，我向一个feature分支（分支develop ）做了大约十几个提交。 为了减少合并回的负担develop ，我从合并后的变化develop到我的feature在这2周的过程分支的3倍。 feature分支已完成，其更改将合并回develop 。

然而，事实证明，在一个月前从develop中分支出来的release分支上也需要此功能。 有没有办法合并来自旧分支的更改，但是省略了我develop的变化3次合并？

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图的以下部分，您将看到，一旦创建了发布分支，就不允许从develop接收任何内容，更不用说任何功能分支了。 发布分支的唯一目的是稳定/合并到实际发布，即合并到master 。

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

• 放弃当前的release分支并创建一个源于develop技巧的新分支，
• 或冻结所有release工作，然后将其重新develop然后再继续develop ，
• 或者等待下一个版本将新功能合并到一个版本中。

如果你没有坚持Git Flow就好了......

如果你愿意在这个问题上反对Git Flow，你可以随时将你的功能release而不会从develop最新事件中将其污染。 以下方法的缺点是您的历史将有点混乱，并将包含“重复提交”; 但是如果您真的坚持将功能从feature分支合并到当前/主动版本中，我认为您没有多少选择。

为方便起见，我们假设你的repo看起来如下（我用字母标记了一些提交）：

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. 退房release

    git checkout release 

2. 获取提交A和feature提示之间的所有非合并提交修订的列表; 在这种情况下，那将是提交B，C，D，E，G，I和J.命令

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

   应该为你做到这一点。

3. 经过修订的该列表cherry-pick ，以应用由这些提交之上引入的变化release ：

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

   你最终会得到这样的东西：

    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. 稳定release分支。

5. 一旦release命中master ，你也应该将它合并到develop ，你应该重新站起来。