【问题标题】:How to undo "git commit --amend" done instead of "git commit"如何撤消完成的“git commit --amend”而不是“git commit”
【发布时间】:2010-11-30 08:34:33
【问题描述】:

我不小心修改了我之前的提交。提交应该是分开的,以保留我对特定文件所做更改的历史记录。

有没有办法撤消最后一次提交?如果我执行git reset --hard HEAD^ 之类的操作,则第一次提交也将被撤消。

(我还没有推送到任何远程目录)

【问题讨论】:

    标签: git commit undo git-amend


    【解决方案1】:

    您需要做的是创建一个新的提交,其细节与当前的HEAD 提交相同,但父级为HEAD 的先前版本。 git reset --soft 将移动分支指针,以便下一次提交发生在与当前分支头现在不同的提交之上。

    # Move the current head so that it's pointing at the old commit
    # Leave the index intact for redoing the commit.
    # HEAD@{1} gives you "the commit that HEAD pointed at before 
    # it was moved to where it currently points at". Note that this is
    # different from HEAD~1, which gives you "the commit that is the
    # parent node of the commit that HEAD is currently pointing to."
    git reset --soft HEAD@{1}
    
    # commit the current tree using the commit details of the previous
    # HEAD commit. (Note that HEAD@{1} is pointing somewhere different from the
    # previous command. It's now pointing at the erroneously amended commit.)
    git commit -C HEAD@{1}
    

    【讨论】:

    • 非常酷,+1。我什至通过git reflog 的倒数第二次修改视图来找到正确的数字,例如{2}.
    • 为了清楚起见,第一个命令是真正的“撤消”。它在git commit --amend 之前生成 HEAD、工作目录(未更改)和索引状态。第二个是对新提交的“重做”。这些适用于任何git commit,而不仅仅是--amend
    • 因此,如果您没有修改需要挽救的新提交消息,则第二部分可以只是普通的git commit
    • 由于某种原因,我在运行 git reset --soft HEAD@{1}: fatal: ambiguous argument 'HEAD@1': unknown revision or path not in the working tree. Use '--' to separate paths from revisions 时遇到错误。当我将HEAD@{1} 替换为git reflog 中显示的等效提交哈希时(感谢JJD!),这个答案非常有效!
    • @TimArnold 取决于您的 shell,您可能需要在 HEAD@{1} 周围加上单引号或双引号。例如,如果我在 tcsh 中运行 echo HEAD@{1},则输出为 HEAD@1,因为大括号是由 tcsh 解释的。如果我使用单引号,则保留大括号。
    【解决方案2】:

    使用ref-log:

    git branch fixing-things HEAD@{1}
    git reset fixing-things
    

    然后,您应该只在您的工作副本中拥有所有之前修改过的更改,并且可以再次提交

    查看以前索引的完整列表类型git reflog

    【讨论】:

    • 这也会擦除索引 - 仍然有用,但超出了简单的“撤消”范围。
    • HEAD@{1}HEAD~1有什么区别吗?
    • @neaumusic:是的! HEAD~1HEAD^ 完全相同,并且标识当前提交的 parent。另一方面,HEAD@{1} 指的是 HEAD 在此之前指向的提交,即当您签出不同的分支或修改提交时,它们表示不同的提交。
    • 第一步是多余的。简单的git reset HEAD@{1} 就够了。
    • 哇,reflog 是指ref-log 而不是re-flog?这更有意义
    【解决方案3】:

    通过以下方式查找修改后的提交:

    git log --reflog
    

    注意:您可以添加--patch 来查看提交的主体以清楚起见。与git reflog相同。

    然后通过以下方式将您的 HEAD 重置为之前的任何提交:

    git reset SHA1 --hard
    

    注意:替换 SHA1 为您的真实提交哈希。另请注意,此命令将丢失任何未提交的更改,因此您可以在之前存储它们。或者,使用--soft 保留最新更改,然后提交。

    然后在上面挑选你需要的另一个提交:

    git cherry-pick SHA1
    

    【讨论】:

    • 如果你做git reset SHA1 --soft,你可以保留最新的更改然后提交。
    【解决方案4】:

    使用HEAD@{1} 的这些答案都没有为我解决,所以这是我的解决方案:

    git reflog

    d0c9f22 HEAD@{0}: commit (amend): [Feature] - ABC Commit Description 
    c296452 HEAD@{1}: commit: [Feature] - ABC Commit Description 
    

    git reset --soft c296452

    您的暂存环境现在将包含您意外与 c296452 提交合并的所有更改。

    【讨论】:

    • 我在已经推送的提交上执行了git commit --amend,因此其他建议不起作用。但这确实做到了。谢谢。
    【解决方案5】:

    如果您已将提交推送到远程,然后错误地修改了对该提交的更改,这将解决您的问题。发出 git log 以在提交前查找 SHA。 (这假设远程被命名为原点)。现在使用该 SHA 发出这些命令。

    git reset --soft <SHA BEFORE THE AMMEND>
    #you now see all the changes in the commit and the amend undone
    
    #save ALL the changes to the stash
    git stash
    
    git pull origin <your-branch> --ff-only
    #if you issue git log you can see that you have the commit you didn't want to amend
    
    git stash pop
    #git status reveals only the changes you incorrectly amended
    
    #now you can create your new unamended commit
    

    【讨论】:

    • 这是更一般的问题的一个特例,但它完全满足了我的迫切需要。
    • 对我来说也一样。我偶尔会在 git rebase 期间遇到冲突,有时我会“修改”而不是“rebase --continue”......这只是一个救生员!
    【解决方案6】:

    你总是可以拆分提交, 来自manual

    • 使用 git rebase -i commit^ 启动交互式 rebase,其中 commit 是您要拆分的提交。事实上,任何提交范围都可以,只要它包含该提交。
    • 使用“编辑”操作标记要拆分的提交。
    • 在编辑该提交时,执行 git reset HEAD^。效果是 HEAD 倒带一,索引也随之而来。但是,工作树保持不变。
    • 现在将更改添加到您希望在第一次提交中拥有的索引。您可以使用 git add(可能以交互方式)或 git-gui(或两者)来执行此操作。
    • 使用现在适当的任何提交消息提交当前索引。
    • 重复最后两个步骤,直到您的工作树干净为止。
    • 使用 git rebase --continue 继续 rebase。

    【讨论】:

    • 太复杂了。 git reflog 就是你所需要的
    • 很多步骤是的,但每个步骤都不复杂且易于操作。这对我有用并得到了我的投票。
    • 此外,此答案允许您有选择地选择您意外“修改”的更改,为 git reset --soft HEAD@{1} 方法提供一些额外的价值(这确实解决了我的问题顺便说一句)
    • 您也可以使用 reflog 方法选择性地选择更改。只需使用git reset 而不是git reset --soft,然后使用git add --patch
    • 这仍然会重写历史并需要强制推送。根据您的情况,这可能是也可能不是问题。
    【解决方案7】:

    可能值得注意的是,如果您仍在编辑器中看到提交消息,您可以删除提交消息,它将中止git commit --amend 命令。

    【讨论】:

      【解决方案8】:

      也许可以使用git reflog 在修改前和修改后获得两次提交。

      然后使用git diff before_commit_id after_commit_id &gt; d.diff 获取修改前和修改后的差异。

      接下来使用git checkout before_commit_id回到提交前

      最后使用git apply d.diff 应用您所做的真正更改。

      这解决了我的问题。

      【讨论】:

        【解决方案9】:

        您可以在下面撤消您的git commit —amend

        1. git reset --soft HEAD^
        2. git checkout files_from_old_commit_on_branch
        3. git pull origin your_branch_name

        ======================================

        现在您的更改与以前一样。这样您就完成了对 git commit —amend 的撤消操作

        现在你可以git push origin &lt;your_branch_name&gt;,推送到分支。

        【讨论】:

          【解决方案10】:

          这晚了将近 9 年,但没有看到提到的这种变化完成了同样的事情(它是其中一些的组合,类似于最佳答案 (https://stackoverflow.com/a/1459264/4642530)。

          搜索分支上的所有分离头

          git reflog show origin/BRANCH_NAME --date=relative

          然后找到SHA1哈希

          重置为旧的 SHA1

          git reset --hard SHA1

          然后把它推回去。

          git push origin BRANCH_NAME

          完成。

          这将使您完全恢复到旧的提交。

          (包括之前覆盖的分离提交头的日期)

          【讨论】:

          • 是的,但我通常想重置 --soft 以保留我的更改。我只是希望它单独提交
          【解决方案11】:
          1. 使用最后一次提交签出到临时分支

            git branch temp HEAD@{1}

          2. 重置上次提交

            git reset temp

          3. 现在,您将拥有您提交的所有文件以及之前的提交。检查所有文件的状态。

            git status

          4. 从 git 阶段重置您的提交文件。

            git reset myfile1.js(以此类推)

          5. 重新附加此提交

            git commit -C HEAD@{1}

          6. 添加文件并将其提交到新提交。

          【讨论】:

            【解决方案12】:

            简单的解决方案 Solution Works Given:如果您的 HEAD 提交与远程提交同步。

            • 在您的本地工作区再创建一个分支,并使其与您的远程分支保持同步。
            • Cherry 从分支中挑选 HEAD 提交(其中 git commit --amend)被执行到新创建的分支上。

            精心挑选的提交将仅包含您的最新更改,而不是旧更改。 您现在可以重命名此提交。

            【讨论】:

              猜你喜欢
              • 2017-05-11
              • 2017-01-08
              • 1970-01-01
              • 2017-04-15
              • 2013-03-06
              • 2014-11-20
              • 1970-01-01
              • 2016-10-09
              相关资源
              最近更新 更多