给定使用 commit
提交的更改,然后使用 revert
还原,那么撤消该还原的最佳方法是什么?
理想情况下,这应该通过新的提交来完成,以免重写历史。
git cherry-pick <original commit sha>
将复制原始提交,实质上是重新应用提交
还原 revert 会做同样的事情,但提交信息更混乱:
git revert <commit sha of the revert>
这两种方法中的任何一种都可以让您在不覆盖历史记录的情况下进行 git push
,因为它会在还原后创建一个新的提交。
键入提交 sha 时,您通常只需要前 5 或 6 个字符:
{2 }
如果您尚未推动该更改,git reset --hard HEAD^
否则,还原还原是非常好的。
另一种方法是先git checkout HEAD^^ -- .
,然后是git add -A && git commit
。
git cherry-pick
或 git revert
似乎是还原还原的最直接方法。
Otherwise, reverting the revert is perfectly fine.
,然后解释 git checkout HEAD^^ -- .
在做什么会很有帮助。
git add -A
...除非您想将每个文件都添加到版本控制中,这很可能不是您想要的。
恢复提交就像 git 中的任何其他提交一样。意思是,您可以还原它,如下所示:
git revert 648d7d808bc1bca6dbf72d93bf3da7c65a9bd746
这显然只有在推送更改后才有意义,尤其是当您无法强制推送到目标分支时(这对您的主分支来说是个好主意)。如果尚未推送更改,只需按照其他帖子进行挑选、还原或简单地删除还原提交。
在我们的团队中,我们有一个规则,对在主分支中提交的 Revert 提交使用 revert,主要是为了保持历史记录干净,以便您可以看到哪个提交还原了什么:
7963f4b2a9d Revert "Revert "OD-9033 parallel reporting configuration"
"This reverts commit a0e5e86d3b66cf206ae98a9c989f649eeba7965f.
...
a0e5e86d3b6 Revert "OD-9055 paralel reporting configuration"
This reverts commit 648d7d808bc1bca6dbf72d93bf3da7c65a9bd746.
...
Merge pull request parallel_reporting_dbs to master* commit
'648d7d808bc1bca6dbf72d93bf3da7c65a9bd746'
这样,你可以追溯历史,找出整个故事,甚至那些不了解遗产的人也可以自己解决。然而,如果你挑选或变基的东西,这些有价值的信息就会丢失(除非你在评论中包含它)。
显然,如果一个提交多次恢复和重新恢复,那将变得非常混乱。
恢复revert就可以了
例如,
如果 abcdef
是您的提交并且 ghijkl
是您在恢复提交 abcdef
时的提交,则运行:
git revert ghijkl
这将还原还原
以下是我的做法:
如果分支 my_branchname
包含在已还原的合并中。我想恢复 my_branchname
:
我首先从 my_branchname
执行 git checkout -b my_new_branchname
。
然后我执行 git reset --soft $COMMIT_HASH
,其中 $COMMIT_HASH
是 my_branchname
的第一次提交之前提交权的提交哈希(请参阅 git log
)
然后我进行新的提交 git commit -m "Add back reverted changes"
然后我向上推新分支 git push origin new_branchname
然后我为新分支发出拉取请求。
如果您不喜欢“reverting a revert”的想法(尤其是当这意味着丢失许多提交的历史信息时),您可以随时查看有关 "Reverting a faulty merge" 的 git 文档。
鉴于以下起始情况
P---o---o---M---x---x---W---x
\ /
A---B---C----------------D---E <-- fixed-up topic branch
(W 是您对合并 M 的初始还原;D 和 E 是对您最初损坏的功能分支/提交的修复)
您现在可以简单地将提交 A 重播到 E,以便它们都不“属于”恢复的合并:
$ git checkout E
$ git rebase --no-ff P
您的分支的新副本现在可以再次合并到 master
:
A'---B'---C'------------D'---E' <-- recreated topic branch
/
P---o---o---M---x---x---W---x
\ /
A---B---C----------------D---E
如果您错误地进行了还原:
git revert <commit-id>
你只需要运行:
git cherry-pick <commit-id>
我必须提交我的更改以使用此命令进行处理。
您可以通过运行以下命令获取您的提交 ID:
git log --pretty=format:"%h - %an, %ar : %s"
或者您可以在 git checkout -b <new-branch>
和 git cherry-pick <commit>
之前到 git rebase
以删除 revert
提交。像以前一样发送拉取请求。
要取回提交后恢复的未暂存和暂存更改:
git reset HEAD@{1}
要恢复所有未暂存的删除:
git ls-files -d | xargs git checkout --
我遇到了一个问题,有人将我的分支恢复为 master,但我需要能够再次合并它,但问题是恢复包含了我的所有提交。让我们看看我们从 M1 创建功能分支的案例,我们在 M3 中合并我们的功能分支并在 RM3 中恢复它
M1 -> M2 -> M3 -> M4- > RM3 -> M5
\. /
F1->F2 -
如何让F2能够合并到M5?
git checkout master
git checkout -b brach-before-revert
git reset --hard M4
git checkout master
git checkout -b new-feature-branch
git reset --hard M1
git merge --squash brach-before-revert
在意外删除所有文件的最初恐慌之后,我使用以下方法取回了我的数据
git reset HEAD@{1}
git fsck --lost-found
git show
git revert <sha that deleted the files>
我看到响应包含命令 git reset --hard HEAD
,没有任何谨慎。由于选项 --hard
,您应该小心使用该命令。它会重置您的索引和远程存储库,但大多数情况下,它还会重置您的本地存储库,并且所有未推送到远程但尚未从本地存储库和索引中提交的提交都将丢失。切勿使用该标志 --hard
除非您确定您还想将所有本地工作从当前提交重置到您选择的哈希值。如果无论如何您做错了,请运行 git reflog
来检索您的 ~hash,然后运行 git reset --hard ~hash
来恢复您的文件。
就我而言,我需要在还原后提交更改,然后才能挑选原始提交而不会失败。
git commit -m "Make changes (original commit)."
git revert <original commit hash>
git commit -m "Revert original commit."
git cherry-pick <original commit hash>