我有一个Git存储库,看起来像这样:
A <- B <- C <- D <- HEAD
我希望分支的头部指向A,即,我希望B、C、D和head消失,我希望头部与A同义。
听起来我可以尝试重新设置基础(不适用,因为我已经在两者之间进行了更改),也可以恢复。但如何恢复多次提交?我一次回复一个吗?订单重要吗?
我有一个Git存储库,看起来像这样:
A <- B <- C <- D <- HEAD
我希望分支的头部指向A,即,我希望B、C、D和head消失,我希望头部与A同义。
听起来我可以尝试重新设置基础(不适用,因为我已经在两者之间进行了更改),也可以恢复。但如何恢复多次提交?我一次回复一个吗?订单重要吗?
当前回答
这是Jakub回答中提供的解决方案之一的扩展。
我面临的情况是,我需要回滚的提交有些复杂,其中几个提交是合并提交,我需要避免重写历史。我无法使用一系列git-restore命令,因为我最终在添加的反转更改之间遇到了冲突。我最终使用了以下步骤。
首先,检查目标提交的内容,同时将HEAD留在分支的顶端:
git checkout -f <target-commit> -- .
(--确保<targetcommit>被解释为提交而不是文件;.指的是当前目录。)
然后,确定在回滚的提交中添加了哪些文件,因此需要删除这些文件:
git diff --name-status --cached <target-commit>
添加的文件应在行的开头显示为“A”,并且不应有其他差异。现在,如果需要删除任何文件,请暂存这些文件以进行删除:
git rm <filespec>[ <filespec> ...]
最后,提交回复:
git commit -m 'revert to <target-commit>'
如果需要,请确保返回到所需状态:
git diff <target-commit> <current-commit>
应该没有区别。
其他回答
git reset --hard a
git reset --mixed d
git commit
这将同时对所有人起到恢复作用。给出一个好的承诺信息。
我真的想避免硬重置,这就是我想到的。
A -> B -> C -> D -> HEAD
返回A(后退4步):
git pull # Get latest changes
git reset --soft HEAD~4 # Set back 4 steps
git stash # Stash the reset
git pull # Go back to head
git stash pop # Pop the reset
git commit -m "Revert" # Commit the changes
我很沮丧,这个问题无法得到回答。其他所有问题都与如何正确还原和保存历史有关。这个问题说:“我希望分支的头部指向A,即我希望B、C、D和head消失,我希望头部与A同义。”
git checkout <branch_name>
git reset --hard <commit Hash for A>
git push -f
我在阅读Jakub的帖子时学到了很多东西,但公司里的一些人(可以在没有Pull Request的情况下推送到我们的“测试”分支)推送了五次错误的提交,试图修复他在五次提交之前犯的错误。不仅如此,还接受了一到两个拉取请求,但现在情况很糟糕。所以忘掉它吧;我找到了最后一个好的提交(abc1234),并运行了基本脚本:
git checkout testing
git reset --hard abc1234
git push -f
我告诉在这个仓库工作的其他五个人,他们最好记录下过去几个小时的变化,并从最新的测试中删除/重新广播。故事结束。
我发现自己需要恢复一系列的提交,然后重新恢复它们,以帮助团队提出明确的拉取请求,而不必强制推送他们的目标分支(直接提交给)
# checkout the branch that should be targeted
git checkout $branch_target
# revert the commits in $branch_target to some $count where
# $count is the number of commits to revert
# cut is used to slice just the commit hash field from each line of output
# xargs runs the command once for each line of input, reversing the commits!
git log --oneline -n $count | cut -d' ' -f1 | xargs git revert
# check out the branch which should be the source of the pull request
git checkout -b $branch_for_pull
# revert the revert commits
# $count is that same number of commits being reverted (again)
git log --oneline -n $count | cut -d' ' -f1 | xargs git revert
# push branches up and go off to create PR in whatever web UI
git push --set-upstream origin $branch_for_pull # it's new!
git checkout $branch_target
git push # if this branch wasn't pushed, just fix the issue locally instead..
因为这会以相反的顺序将所有提交从HEAD还原为git-log-n$count,所以它可以很好地、干净地处理任何数量的提交
在此状态下从$branch_target查看
% git log --oneline origin/$branch_target
ffff006 (origin/$branch_target, $branch_target) Revert "first commit"
ffff005 Revert "second commit"
ffff004 Revert "third commit"
ffff003 third commit
ffff002 second commit
ffff001 first commit
在此状态下从$branch_for_pull查看
% git log --oneline origin/$branch_for_pull
ffff009 (origin/$branch_for_pull, $branch_for_pull) Revert "Revert "third commit""
ffff008 Revert "Revert "second commit""
ffff007 Revert "Revert "first commit""
ffff006 (origin/$branch_target, $branch_target) Revert "first commit"
ffff005 Revert "second commit"
ffff004 Revert "third commit"
ffff003 third commit
ffff002 second commit
ffff001 first commit
如果意图是用变更集创建N个分支,但它们都被提交到同一个分支,您仍然可以将它们全部还原为基本提交,然后只还原所需的还原,因为变更集应该按逻辑排序(试着说5倍快)
使用像HEAD~7..HEAD~5这样的语法可能有助于描述范围以精确地分割还原-还原分支
在这里,当恢复最后7次提交(gitlog-n7),但在一个分支中恢复5次(gitlog-n 5),然后在另一个gitlogHEAD~12..HEAD~10(12是7次提交+5次提交,假设新的PR分支基于“之前”分支,或FF(未压缩)的结果,将分支“之前”合并到原始目标分支中时,这是有意义的
在我看来,一个非常简单和干净的方法可以是:
回到A
git checkout -f A
将master的头指向当前状态
git symbolic-ref HEAD refs/heads/master
save
git commit