Question

我目前有以下情况（简化）。

   master            C --+-- E
                     |   |   |
   hotfix            |   D --+
                     |       |
  develop    A - B - C ----- F - G - H - I
                                     |
  feature                            + J - K - L

我想最终：

   master            C --+-- E ------+
                     |   |   |       |
   hotfix            |   D --+       |
                     |       |       |
  develop    A - B - C ----- F - G - | --- H - I
                                     |
  feature                            + J - K - L

我怎样才能以合适的方式做到这一点？ feature中的所有内容都不依赖于G，因为feature上编辑的所有内容都只是在一个单独的文件夹中。

我已尝试过以下内容（在feature上时），但所有这些似乎都会在F feature之后留下提交痕迹：

 1. git rebase --onto master develop feature
 2. git rebase --onto E J~1
 3. git rebase --onto master develop

Answer 1

樱桃挑选J，K，L从特征到主分支。您将来应该使用一个好的分支策略。我正在使用这个one并且效果非常好。

Answer 2

由于我不能再等待彻底的解决方案，我决定使用cherrypick的建议。虽然，我不想直接在master分支上直接挑选，但这对我的 git flow 工作流程来说是不好的做法。所以我做了以下事情：

启动新的修补程序
```
$ git flow hotfix start vx.x.x
```
Cherry挑选来自feature
的提交
```
$ git cherry-pick J^..L
```
完成修补程序，基本上将挑选出来的提交合并到master和develop
```
$ git flow hotfix finish vx.x.x
```
确保我永远不会通过在feature本地删除它们来合并旧origin分支的提交。
```
$ git branch -d feature
$ git push origin :feature
```

所以，在此之后，我得到了以下内容：

master            C --+-- E --+---------- O
                  |   |   |   |           |
hotfix            |   D --+   J - K - L --+
                  |       |               |
develop   A - B - C ----- F - G - H - I - M

我仍然相信我应该能够通过rebase更优雅地解决这个问题，但我认为这样做的方法非常优雅。

具有复杂历史的git rebase分支

2 个答案: