当我使用了一点源代码后,我做了我通常的事情提交,然后推送到远程存储库。但后来我注意到我忘记在源代码中组织导入。因此,我执行modify命令以替换先前的commit:

> git commit --amend

不幸的是,无法将提交推回到存储库。它是这样被拒绝的:

> git push origin
To //my.remote.repo.com/stuff.git/
 ! [rejected]        master -> master (non-fast forward)
error: failed to push some refs to '//my.remote.repo.com/stuff.git/'

我该怎么办?(我可以访问远程存储库。)


当前回答

快速咆哮:没有人在这里发布简单的答案,这表明了Git CLI显示出的绝望的用户敌意。

无论如何,如果你没有试图强行推动,那么“显而易见”的方法就是先拉动。这将拉动您修改的更改(因此不再具有),以便您再次拥有它。

一旦解决了任何冲突,就可以再次推送。

So:

git pull

如果在pull中出现错误,可能是本地存储库配置有问题(我在.git/config分支部分中有一个错误的ref)。

之后

git push

也许你会得到一个额外的承诺,主题讲述一个“琐碎的合并”。

其他回答

如果要更改的消息是针对存储库的最新提交,则将执行以下命令:

git commit --amend -m "New message"

git push --force repository-name branch-name

注意:除非您确信在最近一次提交后没有其他人克隆过您的存储库,否则不建议使用--force。

更安全的选择是使用:

git push --force-with-lease repository-name branch-name

与-force不同,-force将销毁其他人推送到分支的任何更改,如果存储库有上游更改,-forcewithlease将中止。

如果您还没有将代码推送到远程分支(GitHub/Bitbucket),可以在命令行上更改提交消息,如下所示。

 git commit --amend -m "Your new message"

如果您正在处理特定分支,请执行以下操作:

git commit --amend -m "BRANCH-NAME: new message"

如果您已经用错误的消息推送了代码,那么在更改消息时需要小心。即,在您更改提交消息并再次尝试推送后,您最终会遇到问题。要使其平滑,请执行以下步骤。

请在做之前阅读整个答案

git commit --amend -m "BRANCH-NAME : your new message"

git push -f origin BRANCH-NAME                # Not a best practice. Read below why?

重要提示:当您直接使用强制推送时,您可能会遇到其他开发人员正在同一分支上工作的代码问题。因此,为了避免这些冲突,您需要在强制推送之前从分支中提取代码:

 git commit --amend -m "BRANCH-NAME : your new message"
 git pull origin BRANCH-NAME
 git push -f origin BRANCH-NAME

如果提交消息已经被推送,这是更改提交消息时的最佳做法。

快速咆哮:没有人在这里发布简单的答案,这表明了Git CLI显示出的绝望的用户敌意。

无论如何,如果你没有试图强行推动,那么“显而易见”的方法就是先拉动。这将拉动您修改的更改(因此不再具有),以便您再次拥有它。

一旦解决了任何冲突,就可以再次推送。

So:

git pull

如果在pull中出现错误,可能是本地存储库配置有问题(我在.git/config分支部分中有一个错误的ref)。

之后

git push

也许你会得到一个额外的承诺,主题讲述一个“琐碎的合并”。

事实上,我曾经用武力和.git存储库推过一次,结果被Linus BIG TIME骂了一顿。一般来说,这会给其他人带来很多问题。一个简单的答案是“不要这样做”。

我看到其他人给出了这样做的方法,所以我在这里不再重复。但这里有一个提示,在您使用--force(或+master)推出修改后的提交后,可以从这种情况中恢复过来。

使用gitreflog查找您修改的旧提交(称之为旧提交,我们将调用您通过修改新提交创建的新提交)。在新旧之间创建一个合并,记录新的树,比如git checkout new&&git merge-s our old。使用gitmergemaster将其合并到您的master用git push更新你的主人。头部:主将结果推出来。

然后,那些不幸地将他们的工作建立在你通过修改和强制推动而消除的承诺之上的人将看到由此产生的合并,他们将看到你喜欢新的而不是旧的。他们后来的合并将不会看到由于您的修改而导致的新旧冲突,因此他们不必遭受损失。

我通过放弃本地修改的提交并在顶部添加新的更改来解决这个问题:

# Rewind to commit before conflicting
git reset --soft HEAD~1

# Pull the remote version
git pull

# Add the new commit on top
git add ...
git commit
git push