注意：这种情况的产生更多的是一个故事，即与IMO无关的
给出以下git commit图，从最旧的开始，全部推入原点
start
|
breaking
/ \
fix #0 work
| |
fix #1(master) morework(issue-fix)
我需要将分支（问题修复）移动到基于开始而不是中断的位置，即将其变为
start
/ \
breaking |
| |
fix #0 work
| |
fix #1(master) morework(issue-fix)
中断的更改与问题修复（项目的不同部分）无关，但是由于测试也涵盖了项目的那部分，因此它们会导致该分支的CI失败。
我以为可以进行rebase操作，但是在检查了更多工作之后，尝试在SourceTree中执行任何操作，手动运行git rebase start只会打印Current branch issue-fix is up to date
是否有一种干净有效的方法？我不想新建分支，如果不需要的话，可以手动移动所有内容。
编辑：此外，问题修复已被拉入另一个分支，从而在那里也引入了错误的提交。相同的程序会在那里工作，还是在问题修复程序上中断该分支？
答案 0 :(得分：4)
您应该使用交互式变基来摆脱breaking分支中的issue-fix提交。
根据您的情况，您应该签出到issue-fix分支并执行以下操作：
git rebase -i HEAD~3
然后，当编辑器打开时，您应该能够选择要离开的提交和要删除的提交：
drop 2dsafa ... will delete the commit you want to get rid of
pick sdfsadf .. will leave this commit
pick dfsa4sdc .. will leave this commit
如果您的issue-fix分支已经以其中断状态合并到其他分支中，那么事情将变得更加复杂。
在这种情况下，我建议使用交互式资源库来摆脱其他分支的issue-fix提交。之后，我将在issue-fix顶部将来自其他分支的提交重新设定为基准。
答案 1 :(得分：1)
git rebase --onto start work^ issue-fix
它将尝试将提交内容从work（包括）移动到issue-fix的尖端，移动到新的基础start上。
如果要跳过或压缩某些提交，请与-i一起使用交互模式。交互式页面将向您展示如何操作。
如果要保留合并提交，可以添加-p。要保留空的提交，请使用--keep-empty。
您可能还有其他一些问题没有提到。但很可能您可以在git rebase的手册中找到适当的选项。
答案 2 :(得分：0)
您需要为此运行交互式变基。
在分支issue-fix上运行：git rebase --interactive start
这应该弹出编辑器：
pick breaking <commit message>
pick work <commit message>
pick morework <commit message>
您应该将“ pick”从第一行更改为“ drop”-即，您想从分支中删除breaking提交，并将其重新设置到start的顶部。
保存并关闭编辑器。
运行git log来检查结果。
一如既往，在更改基准时，请注意更改提交哈希，即，即使提交work和morework look 相同，其父母也会发生变化，导致各自提交哈希以进行更改。
如果issue-fix是共享分支，则可能存在危险。
如果您不确定是否有人已经拉过您的issue-fix分支，我会选择git revert breaking。
这是一个安全的选择，不会弄乱您的分支历史记录（它只会添加另一个“取消” breaking的提交）。