我正在研究一个月前从master分支出来的功能分支B。随着其他新功能的出现，master分支不断更新。
这是master分支现在的样子：
1 -> 2 -> 3 -> 4 -> 5 -> 6 ->7
当我第一次分支时，它看起来像这样：
1 -> 2 -> 3
这是我的功能分支（B）现在的样子：
x -> y -> z
现在我已经准备好将新功能推向master了，建议我先从master恢复基础，然后创建PR。
在进行git rebase时，我的分支遇到了几个文件的合并冲突。我以为我会保留即将来临的更改，并且重新设置将正常进行。但是，我解决了冲突，将整个“ REBASE MASTER”步骤转换为某种“ MERGE MASTER”。又名：它将已经合并到master中的提交应用到了我的功能分支中，而不是我最初打算使用git rebase做的事情。
这是我的功能分支现在的样子：
x -> 4 -> 5 -> 6 -> y -> 7 -> z
这是我想要实现的（但不是）：
1 -> 2 -> 3 -> 4 -> 5 -> 6 ->7 -> x -> y -> z
如何返回？它已经被推送到远程分支，所以我不能简单地删除本地分支并再次从源中获取。
我可以想到的一种方法是再次从master分支出来，并创建一个功能分支C。然后，从B到C进行Cherry-pick提交。一旦我确定C是B的完整副本（并且仅包含我想要的提交），我可以删除B。我丢失了什么吗？还是有更好/更快的方法？
答案 0 :(得分：2)
（首先，以防万一，使用git rebase --abort中止仍在进行的所有重新设置）
您是唯一从事此功能分支的人吗？ （我想是这样，以下我会假设）
公关是否已经被接受/合并为主人？
如果不是，那么这将是非常无法避免的情况。 （这可能是勒克斯在评论中暗示的内容）
首先，找到您需要还原的提交哈希（在您的示例中为z）。为此，您可以检查分支机构的reflog（或者可以从最近的命令输出中选择它）（如果有）。
然后将您的本地分支B恢复到旧引用（在变基之前），然后将其再次推送到远程（使用--force，因为git会抱怨这不是线性历史记录）。
git branch -f B <commit_hash_of_z>
git push -f origin B
现在，您可以重做基准，并尝试弄清上次转换的位置。
答案 1 :(得分：1)
有一个用于还原签到的选项，它本身可以作为单独的签到。
但是我建议您仔细进行阅读。
https://www.atlassian.com/git/tutorials/undoing-changes/git-revert
我也希望您能理解“将A重设在B上”和“将A与B合并”的区别
我会建议您是否要重新设置基准，请在本地上更新master的来源。（这是我对事情进行管理的技巧，我不知道它是否是标准的）