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

Question

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

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

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

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

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

如果您真的坚持使用Git Flow模型，那么

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

如果你没有坚持使用Git Flow就行了......

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

为方便起见，我们假设您的仓库看起来如下（我已用信件标记了一些提交）：

feature

你能做的是

1. 查看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]

   release

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

   feature

   应该为你做。

3. 将该修订列表传递给git rev-list --no-merges A..feature ，以便在cherry-pick之上应用这些提交所引入的更改：

   release

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

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

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

5. release点击release后，您还应该将其合并到master，然后您应该重新站起来。