仅使用git-restore<commit_hash>是行不通的。显然,必须指定-m。
当前回答
下面是一个完整的示例:
git revert -m 1 <commit-hash>
git push -u origin master
git还原。。。提交您的更改。
-m1表示您希望在合并之前恢复到第一个父级的树,如下面的答案所述。<commit hash>是要还原的合并的提交哈希。
git推。。。将更改推送到远程分支。
其他回答
正确标记的答案对我有用,但我必须花一些时间来确定发生了什么。所以我决定为我这样的情况添加一个简单明了的答案。。
假设我们有分支A和B。您将分支A合并到分支B中,并将分支B推到自身,因此现在合并是它的一部分。但是您希望返回到合并之前的最后一次提交。。你是做什么的?
转到git根文件夹(通常是项目文件夹)并使用git日志您将看到最近提交的历史记录-提交具有提交/作者/日期财产,而合并也具有合并属性-因此您可以这样看它们:提交:<commitHash>合并:<parentHashA><parentHashB>作者:<Author>日期:<Date>使用gitlog<parentHashA>和gitlog<ParetHashB>-您将看到这些父分支的提交历史记录-列表中的第一个提交是最新的获取所需提交的<commitHash>,转到git根文件夹并使用git checkout-b<newBranchName><commitHash>,这将从合并前选择的最后一次提交开始创建一个新分支。。瞧,准备好了!
为了保持日志的整洁(这种方法有一些缺点(由于push-f)):
git checkout <branch>
git reset --hard <commit-hash-before-merge>
git push -f origin HEAD:<remote-branch>
“合并前提交哈希”来自合并后的日志(gitlog)。
如果您希望恢复刚才所做的更改,这是一个非常简单的答案:
commit 446sjb1uznnmaownlaybiosqwbs278q87
Merge: 123jshc 90asaf
git revert -m 2 446sjb1uznnmaownlaybiosqwbs278q87 //does the work
正如Ryan所提到的,git-restore可能会使合并变得困难,因此git-restore也许不是您想要的。我发现在这里使用git reset-hard<commit hash before merge>命令更有用。
完成硬重置部分后,可以强制推送到远程分支,即git push-f<remote name><remote branch name>,其中<remote name>通常被命名为origin。从那时起,如果您愿意,可以重新合并。
在git-restore-m中,-m选项指定父编号。这是需要的,因为合并提交有多个父级,Git无法自动知道哪个父级是主线,哪个父级就是要取消合并的分支。
当您在git日志的输出中查看合并提交时,您将看到其父级列在以merge开头的行中:
commit 8f937c683929b08379097828c8a04350b9b8e183
Merge: 8989ee0 7c6b236
Author: Ben James <ben@example.com>
Date: Wed Aug 17 22:49:41 2011 +0100
Merge branch 'gh-pages'
Conflicts:
README
在这种情况下,git revert 8f937c6-m 1将获得8989ee0中的树,而git rever-m 2将恢复7c6b236中的树。
为了更好地理解父ID,可以运行:
git log 8989ee0
and
git log 7c6b236
推荐文章
- 为什么我需要显式地推一个新分支?
- 如何撤消最后的git添加?
- Rubymine:如何让Git忽略Rubymine创建的.idea文件
- Gitignore二进制文件,没有扩展名
- Git隐藏错误:Git隐藏弹出并最终与合并冲突
- 了解Git和GitHub的基础知识
- 没有。Git目录的Git克隆
- Git与Mercurial仓库的互操作性
- 忽略git中修改(但未提交)的文件?
- “git restore”命令是什么?“git restore”和“git reset”之间有什么区别?
- Git合并与强制覆盖
- Git拉另一个分支
- 在Bash命令提示符上添加git分支
- 如何更改Git日志日期格式
- git pull -rebase和git pull -ff-only之间的区别