git rebase 在其他分支上

Question

鉴于以下情况：

• 我们针对不同的主题分支开发功能。
• 在发布之前，我们将所有主题分支合并到master。然后在该分支上开始持续集成
• 此外，我们还直接在主分支上进行小改动（拼写错误等...）
• 如果一切正常，我们会将 master 分支中的所有更改合并到 relase 分支中。然后将发布此版本分支

只要我们的测试没有问题，这个工作流程就很好。但是一旦我们决定不从 master 发布一个特性，我们就会遇到麻烦。

例如：

• 我们有 5 个不同功能的主题分支
• 我们将它们全部合并到master
• 除此之外，我们还直接在 master 上进行了 2 个单独的提交（我们修复了一些拼写错误）
• 现在我们发现，5 个功能中的 1 个没有按预期工作，我们无法发货
• 我们仍然希望发布其他 4 个功能（+ 直接在 master 上进行的 2 个提交）

我们现在唯一的选择是： - 将 4 个主题分支直接合并到发布中 - 将 master 上的 2 个提交挑选到发布中

这可能相当烦人，尤其是当我们不跟踪直接在 master 上进行的提交并且数量增加时。

我想要一个我们能够做到的场景：

• 查看所有提交（或更好：合并的分支）
• 放弃我们不希望在下一版本中进行的所有更改
• 将所有其他更改合并到版本中

我已经做了一些研究并遇到了git rebase。 git rebase --interactive 非常接近我的预期。

最好的情况是：

• 以交互方式将所有更改从 master 更改为 release
• 删除我不需要的所有提交（或更好的分支）
• release 只包含我想要的更改

问题是：

当我这样做时：

git checkout master
git rebase --interactive release
<changes>

我最终修改了 master 分支而不是 release 分支。添加--onto release 选项也无济于事。

是否有可能将 rebase 的结果提交到另一个分支上？

问候 雷夫

Answer 1

我对这个问题的理解是，你将 5 个不同的分支合并到 master，然后在合并到 release 之前，你意识到 5 个分支中有一个有错误，所以你只想保留另外 4 个。

既然如此，你为什么不git revert 错误分支的合并提交并继续其余的工作？我有什么遗漏吗？

Answer 2

为了将来参考，请查看Revert a faulty merge，它解释了“撤消”合并的一些场景。此外，请参阅 Git rebase 手册 Recovering From Upstream Rebase 和 Pro Git - Rewriting History 中的警告。如果您还没有，请查看Git project's workflow 和A successful Git branching model。

未来更好的工作流程可能是将功能分支合并到发布分支上，并且只有在通过测试、QA、用户接受等之后才将发布分支合并到master。我通常会等待正确地执行此合并在发布日期之前。您始终可以在发布日期之前进一步进行测试合并，以确保不会出现任何合并冲突意外。

要修复您当前的情况，假设我们有以下历史记录，其中包含两次修复提交和五次功能分支合并提交：

$ git --no-pager log --oneline --decorate --all --graph
*   e202262 (HEAD, master) Merge branch 'f5'
|\  
| * d9930ca (f5) f5
* |   f9d743b Merge branch 'f4'
|\ \  
| * | eea7737 (f4) f4
| |/  
* |   c84ad9f Merge branch 'f3'
|\ \  
| * | 135c7f7 (f3) f3
| |/  
* |   65ed393 Merge branch 'f2'
|\ \  
| * | 9a9b5b6 (f2) f2
| |/  
* |   76ae0e8 Merge branch 'f1'
|\ \  
| * | 8a02982 (f1) f1
| |/  
* | ace81a9 fix 2
* | d4b32e1 fix 1
|/  
* ab6d5b0 A

我会做的是：

1. reset master 到 ab6d5b0 提交。
2. 创建一个release 分支。
3. 将fix 1 和fix 2 提交添加到发布分支。
4. 假设f2 是有问题的功能，请将f1、f3、f4 和f5 分支合并到release 分支上。
5. 在测试过程中，将release 与master 进行试运行合并。
6. 如果一切正常，请将release 合并到master。

以下是使用上述历史记录执行这些步骤的命令（有关这些命令的更多信息，请参阅Git reference manual）：

# Reset master to before the fix and merge commits
git checkout master
git reset --hard ab6d5b0
# Create a release branch
git checkout -b release
# Add the fix commits back
git cherry-pick d4b32e1
git cherry-pick ace81a9
# Merge feature branches
git merge f1
git merge f3
git merge f4
git merge f5
# Dry run merge
git checkout master
git merge --no-ff --no-commit release
git reset --hard HEAD
# Merge release to master
git checkout master
git merge --no-ff release

这将为您留下以下历史记录：

$ git --no-pager log --oneline --decorate --all --graph
*   e24c16e (HEAD, master) Merge branch 'release'
|\  
| *   d23369a (release) Merge branch 'f5' into release
| |\  
| | * d9930ca (f5) f5
| |/  
|/|   
| *   8b90602 Merge branch 'f4' into release
| |\  
| | * eea7737 (f4) f4
| |/  
|/|   
| *   926c094 Merge branch 'f3' into release
| |\  
| | * 135c7f7 (f3) f3
| |/  
|/|   
| *   e964e13 Merge branch 'f1' into release
| |\  
| | * 8a02982 (f1) f1
| |/  
|/|   
| * bb5f6f5 fix 2
| * e8ffeef fix 1
|/  
| * 9a9b5b6 (f2) f2
|/  
* ab6d5b0 A

由于发布准备是在单独的分支上完成的，master 保持干净，并且可能会缓解因功能选择问题而导致的发布管理难题。