Question

给出以下场景：

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

只要我们的测试没有任何问题，这个工作流程就可以了。但是一旦我们决定不从主人那里发送一个功能，我们就会遇到麻烦。

例如：

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

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

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

我想有一个场景，我们可以：

查看所有提交（或更好：合并的分支）
放弃我们在下一版本中不想要的所有更改
将所有其他更改合并到发布中

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

最好的方案是：

将所有更改从master更改为交互式发布
删除我不需要的所有提交（或更好的分支）
发布只有我想要的更改

但问题是：

当我这样做时：

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

我要做的是：

reset master到ab6d5b0提交。
创建release分支。
将fix 1和fix 2提交添加到发布分支。
假设f2是有问题的功能，请将f1，f3，f4和f5分支合并到release分支上。< / LI>
正在进行测试时，请将release合并到master上。
如果一切正常，请将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仍然是干净的，并且可以减轻由于功能选择问题导致的发布管理问题。

git rebase在其他分支上

2 个答案: