如何"取消恢复"恢复的Git提交?

Jim*_*Joo 421 git undo revert

鉴于已经提交的更改已经使用commit,然后还原使用revert,那么撤消该恢复的最佳方法是什么?

理想情况下,这应该使用新的提交来完成,以便不重写历史记录.

Ste*_*han 408

git cherry-pick <original commit sha>
将制作原始提交的副本,实质上是重新应用提交

恢复还原将执行相同的操作,并提供更复杂的提交消息:
git revert <commit sha of the revert>

这些方法中的任何一种都可以在git push不覆盖历史记录的情况下使用,因为它会在还原后创建新的提交.
键入commit sha时,通常只需要前5个或6个字符:
git cherry-pick 6bfabc

  • 这是OP问题的最优雅和完整的解决方案.比它所接受的答案要好得多,因为它假定恢复提交位于提交树的HEAD.op还专门要求一个不会重写历史记录的解决方案,因此在接受的答案中提供的硬解决方案是完全错误的. (56认同)
  • @JimmidyJoo 我对 SO 约定一无所知。但作为一名谷歌搜索者,我真的更喜欢看到更好的答案被选中。并感谢任何人为维持过去的问题所做的努力。 (9认同)
  • @Timo为了澄清,接受的答案包含我使用的解决方案("还原恢复"),并在我的问题的几个小时内发布 - 比这个答案清晰*3年前*.因此,复选标记. (6认同)
  • @JimmidyJoo我知道我迟到了3年,我只是想让人们通过Google搜索来到这里,以找到更好的答案 (5认同)
  • 当我进行合并提交时,这对我不起作用. (4认同)
  • @Stephan 是的,但再次澄清 - 这是一个更好的答案,而不是我用来解决问题的答案。我只是在评论为什么复选标记在哪里。所有人的问题:SO 惯例是否规定我应该“保留”我过去的问题并在新答案出现时重新分配复选标记? (3认同)
  • @JimmidyJoo我认为应该编辑原始答案以反映时代的变化,至少这是我尝试做的,如果他/她未能做到这一点,那么新的更好的答案将接管并应该进行检查。至少我总是这样做。 (2认同)
  • @adnanmuttaleb /sf/answers/3758545521/ 完美地解释了这一点。 (2认同)

Ada*_*ruk 339

如果你尚未推动这一改变, git reset --hard HEAD^

否则,恢复还原完全没问题.

另一种方式是git checkout HEAD^^ -- .然后git add -A && git commit.

  • 请注意,如果要在不立即将原始更改应用于主分支的情况下取消恢复,则可以(1)恢复原始分支(如果已删除),(2)单击恢复分支上的"恢复"**,如下所示Adam,然后(3)在结果PR的标题中单击"编辑",并将目标分支更改为原始分支而不是主分支.现在可以重新合并原始分支以实现先前还原的更改. (7认同)
  • 天啊,不要使用 `git add -A` ...除非您想将每个文件添加到版本控制中,这很可能不是您想要的。 (6认同)
  • 请注意,这将删除工作树和索引中的所有更改。使用 git stash 保存您不想丢失的任何更改。 (3认同)
  • checkout &amp;&amp; commit方法的优点是什么?在一般情况下,“ git cherry-pick”或“ git revert”似乎是还原还原的最直接方法。 (3认同)
  • 我认为这将有助于显示如何:`否则,还原还原是完全可以的。`,然后解释`git checkout HEAD ^^-。'在做什么。 (3认同)

Nes*_*aev 22

还原提交就像git中的任何其他提交一样.意思是,您可以将其还原,如:

git revert 648d7d808bc1bca6dbf72d93bf3da7c65a9bd746
Run Code Online (Sandbox Code Playgroud)

这显然只有在推动更改后才有意义,特别是当您无法强制推送到目标分支时(这对您的分支来说是一个好主意).如果没有推送更改,只​​需按照其他帖子进行挑选,还原或简单地删除还原提交.

在我们的团队,我们有一个规则使用还原上都致力于在主要分支还原的意见,主要是为了保持历史的清洁,这样就可以看到其呈交恢复的内容:

      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'
Run Code Online (Sandbox Code Playgroud)

通过这种方式,您可以追踪历史记录并找出整个故事,即使是那些不了解遗产的人也可以自己解决问题.然而,如果你摘樱桃重订的东西,这些有价值的信息丢失(除非你将其包含在注释).

显然,如果一个提交还原并重新还原不止一次,那就会变得非常混乱.


Aff*_*lem 11

如果您错误地进行了恢复:

git revert <commit-id>
Run Code Online (Sandbox Code Playgroud)

你只需要运行:

git cherry-pick <commit-id>
Run Code Online (Sandbox Code Playgroud)

我必须使用此命令提交我的更改以进行处理。

您可以通过运行以下命令获取您的提交 ID:

git log --pretty=format:"%h - %an, %ar : %s"
Run Code Online (Sandbox Code Playgroud)


Dre*_*eur 7

我是这样做的:
如果分支my_branchname包含在已恢复的合并中。我想恢复原状my_branchname

我先做一个git checkout -b my_new_branchnamefrom my_branchname
然后我做了git reset --soft $COMMIT_HASH这里$COMMIT_HASH是提交的提交正确的哈希的第一次提交的my_branchname(见git log
然后我提出一个新的提交git commit -m "Add back reverted changes"
,然后我推了新的分支git push origin new_branchname
,然后我做了新的分支拉请求。


小智 7

还原还原就能解决问题

例如,

如果abcdef是您的提交,并且ghijkl是还原提交时拥有的提交abcdef,请运行:

git revert ghijkl
Run Code Online (Sandbox Code Playgroud)

这将还原还原

  • 这是正确的答案。它还澄清了恢复本身就是不可恢复的提交。 (2认同)

Nob*_*are 5

如果您不喜欢“恢复恢复”的想法(特别是当这意味着丢失许多提交的历史信息时),您可以随时参阅有关“恢复错误合并”的 git 文档。

考虑到以下起始情况

 P---o---o---M---x---x---W---x
  \         /
   A---B---C----------------D---E   <-- fixed-up topic branch
Run Code Online (Sandbox Code Playgroud)

(W 是合并 M 的初始恢复;D 和 E 是对最初损坏的功能分支/提交的修复)

现在,您可以简单地重播提交 A 到 E,这样它们都不“属于”恢复的合并:

$ git checkout E
$ git rebase --no-ff P
Run Code Online (Sandbox Code Playgroud)

现在可以再次合并分支的新副本master

   A'---B'---C'------------D'---E'  <-- recreated topic branch
  /
 P---o---o---M---x---x---W---x
  \         /
   A---B---C----------------D---E
Run Code Online (Sandbox Code Playgroud)