git - 使用 Git 将开发上的功能分支的所有更改 merge 到发布分支

Question

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

我不确定如何在此分支模型中处理这种情况。

在几周的时间里，我对 feature 分支(从 develop 分支出来)进行了大约十二次提交。为了减轻 merge 回 develop 的负担，我在这 2 周内将 develop 的更改 merge 到我的 feature 分支 3 次。 feature 分支已完成，其更改已 merge 回 develop。

然而，事实证明，大约一个月前从 develop 分支出来的 release 分支也需要此功能。有没有一种方法可以只 merge 那个旧分支的更改，而忽略我 merge 到其中 3 次的对 develop 的更改？

Answer 1

根据 Git Flow 模型，你误了火车

你的 repo 必须看起来像这样:

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 中)的功能 merge 到 release 分支中已经太晚了。这是 Git Flow 所不允许的。

如果您查看主要 nvie.com 的以下部分图表，您会看到，一旦创建了发布分支，就不允许它从 develop 接收任何内容，更不用说任何功能分支了。发布分支的唯一目的是稳定/整合实际发布，即 merge 到 master。

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

• 要么放弃当前的 release 分支并创建一个源于 develop 的新分支，
• 或卡住release 上的所有工作，然后在恢复工作之前将其重新设置为develop，
• 或等待下一个版本将您的新功能 merge 到一个版本中。

如果你可以不坚持 Git Flow...

如果您愿意在这一点上反对 Git Flow，您总是可以将您的功能添加到 release 中，而不会因 develop 的最新内容而污染它。以下方法的缺点是您的历史会有点困惑并且包含“重复提交”；但如果您真的坚持将 feature 分支中的功能 merge 到当前/事件版本中，我认为您没有太多选择。

为方便起见，我们假设您的存储库如下所示(我用字母标记了一些提交):

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. 查看发布

   git checkout release
   

2. 获取在提交 A 和 feature 之间的所有非 merge 提交的修订列表；在这种情况下，这将是提交 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，您也应该将其 merge 到 develop 中，然后您应该重新站起来。