我正在研究一个月前我从大师那里扩展出来的功能分支B.随着其他新功能的出现，主分支不断更新。
这就是master branch现在的样子：
1 -> 2 -> 3 -> 4 -> 5 -> 6 ->7
当我第一次扩展时，它看起来像这样：
1 -> 2 -> 3
这就是我的功能分支（B）现在的样子：
x -> y -> z
既然我已经准备好将我的新功能推向掌握，我被建议先从主人那里重新定位，然后创建一个PR。
在做git rebase时，我的分支遇到了与几个文件的合并冲突。我以为我会保留传入的更改，并且rebase将正常进行。但是，我解决冲突将整个“REBASE MASTER”步骤转换为某种“MERGE MASTER”。 AKA：它将已经合并到master中的提交应用到我的功能分支中，而不是我最初打算用git rebase做的事情。
这就是我的功能分支现在的样子：
x -> 4 -> 5 -> 6 -> y -> 7 -> z
这是我想要实现的目标（但没有）：
1 -> 2 -> 3 -> 4 -> 5 -> 6 ->7 -> x -> y -> z
我怎么回去？这已经被推送到远程分支，所以我不能简单地删除我的本地分支并再次从原点获取。
我能想到的一种方法是再次从master分支，并创建一个功能分支C.然后，cherry-pick从B提交到C.一旦我确定C是B的完整副本（并且只包含提交我我想删除B.我错过了什么吗？还是有更好/更快的方式？
（首先，为了以防万一，中止任何仍在进行中与git rebase --abort相关的基础）
你是唯一一个在这个功能分支上工作的人吗？ （我想是的，我会假设以下）
公关被接受/合并为主人吗？
如果没有，那么这是一个非常可撤销的情况。 （这可能是勒克斯在评论中暗示的）
首先，找到需要恢复的提交哈希值（在您的示例中为z）。为此，您可以检查您的分支机构的reflog（或者如果可用的话，可以从您最近的命令输出中选择它）。
然后将本地分支B恢复到旧参考（在rebase之前）并再次将其推送到远程（使用--force，因为git会抱怨这不是线性历史记录）。
git branch -f B <commit_hash_of_z>
git push -f origin B
现在你可以重做你的rebase，并试着弄清楚它上次横向走向何方。
有一个选项可以恢复办理登机手续，也可以单独办理登机手续。
但我会建议你仔细阅读并读出来。
https://www.atlassian.com/git/tutorials/undoing-changes/git-revert
另外，我希望你理解“B上的rebase A”和“B与A合并”的区别
我会建议你是否做了rebase，请在本地更新master的来源。（这是我保持位管理的诀窍，我不知道它是否是标准的）