如何将修改后的提交推送到远程Git存储库？

问题描述 投票：581回答：14

当我使用我的源代码工作时，我做了我惯常的事情提交，然后我推送到远程存储库。但后来我注意到我忘了在源代码中组织我的导入。所以我做了修改命令来替换以前的提交：

> 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 git-commit amend
14个回答
468
投票

我实际上曾经用--force和.git存储库推动并被Linus BIG TIME骂。一般来说，这会给其他人带来很多问题。一个简单的答案是“不要这样做”。

我看到其他人给出了这样做的秘诀，所以我不会在这里重复。但是在使用--force（或+ master）推出修改后的提交后，这里有一个提示可以从情况中恢复。

  1. 使用git reflog查找您修改的旧提交（称之为old，我们将调用您通过修改new创建的新提交）。
  2. 在old和new之间创建一个合并，记录new的树，就像git checkout new && git merge -s ours old一样。
  3. 用git merge master将它合并到你的主人身上
  4. 使用git push . HEAD:master更新您的主人的结果
  5. 推出结果。

然后，那些不幸的人将你的工作建立在你通过修改和强制推动而消除的提交基础上的人将会看到由此产生的合并会看到你更喜欢new而不是old。他们后来的合并将不会发现你的修改导致的old和new之间的冲突，所以他们不必受苦。

3
投票

您收到此错误，因为Git远程已有这些提交文件。你必须强制推动分支才能工作：

git push -f origin branch_name

还要确保从远程提取代码，因为团队中的其他人可能已将其推送到同一分支。

git pull origin branch_name

这是我们必须强制将提交推送到远程的情况之一。

2
投票

在您制作了git add "your files"和git commit --amend后，这是一种非常简单而干净的方式来推动您的更改：

git push origin master -f

要么：

git push origin master --force
1
投票

我不得不通过从远程仓库中提取并解决出现，提交然后推送的合并冲突来解决这个问题。但我觉得有更好的方法。

1
投票

我只是继续做Git告诉我的事情。所以：

  • 因修改提交而无法推送。
  • 我建议拉一下。
  • 合并失败。所以我手动修复它。
  • 创建一个新的提交（标记为“merge”）并推送它。
  • 它似乎工作！

注意：修改后的提交是最新的提交。

0
投票

在这里，我如何在以前的提交中修复编辑：

  1. 到目前为止保存你的工作。
  2. 暂时保留你的更改，如果做的话：git stash现在你的工作副本在你上次提交的状态下是干净的。
  3. 进行编辑和修复。
  4. 在“修改”模式下提交更改：git commit --all --amend
  5. 您的编辑器将出现请求日志消息（默认情况下，旧日志消息）。如果对它感到满意，请保存并退出编辑器。 新的更改将添加到旧提交中。亲身体验git log和git diff HEAD^
  6. 重新应用您的隐藏更改，如果做出：git stash apply
256
投票

您正在看到Git安全功能。 Git拒绝使用您的分支更新远程分支，因为您的分支的头部提交不是您正在推送的分支的当前头部提交的直接后代。

如果不是这种情况，那么两个人几乎同时推到同一个存储库就不会知道有一个新的提交同时进入，并且推送到最后的人将失去前一个推送器的工作而没有任何一个他们意识到这一点

如果你知道你是唯一一个推动你想要推送修改后的提交或推送一个返回分支的提交的人，你可以通过使用-f开关“强制”Git来更新远程分支。

git push -f origin master

即使这可能也行不通，因为Git允许远程存储库通过使用配置变量receive.denynonfastforwards来拒绝远端的非快速推送。如果是这种情况，拒绝原因将如下所示（请注意'远程拒绝'部分）：

 ! [remote rejected] master -> master (non-fast forward)

要解决这个问题，您需要更改远程存储库的配置，或者作为脏黑客，您可以删除并重新创建分支：

git push origin :master
git push origin master

通常，git push的最后一个参数使用格式<local_ref>:<remote_ref>，其中local_ref是本地存储库上分支的名称，remote_ref是远程存储库上分支的名称。此命令对使用两个shorthands。 :master有一个null local_ref，这意味着将空分支推送到远程端master，即删除远程分支。没有:的分支名称意味着将具有给定名称的本地分支推送到具有相同名称的远程分支。 master在这种情况下是master:master的缩写。

206
投票

快速咆哮：这里没有人发布简单答案的事实证明了Git CLI表现出的绝望的用户敌意。

无论如何，假设你还没有试图强行推动，那么“明显”的做法是先拉。这会拉动您修改的更改（因此不再具有），以便您再次使用它。

解决任何冲突后，您可以再次推送。

所以：

git pull

如果你在pull中出错，可能是你的本地存储库配置有问题（我在.git / config分支部分有一个错误的引用）。

之后

git push

也许你会得到额外的提交，主题讲述“琐碎的合并”。

97
投票

简短的回答：不要将修改后的提交推送到公共回购。

答案很长：一些Git命令，如git commit --amend和git rebase，实际上重写了历史图表。只要你没有公布你的更改，这很好，但是一旦你做了，你真的不应该在历史上徘徊，因为如果有人已经得到你的改变，那么当他们试图再次拉动时，它可能会失败。您应该只使用更改进行新的提交，而不是修改提交。

但是，如果你真的想要推送修改后的提交，你可以这样做：

$ git push origin +master:master

领先的+标志将强制推动发生，即使它不会导致“快进”提交。 （当您推送的更改是公共存储库中已有更改的直接后代时，会发生快进提交。）

44
投票

在您制作了commit --amend之后，这是一种非常简单而干净的方式来推动您的更改：

git reset --soft HEAD^
git stash
git push -f origin master
git stash pop
git commit -a
git push origin master

具体如下：

  • 将分支头重置为父提交。
  • 存放最后一次提交。
  • 强制推送到远程。远程现在没有最后一次提交。
  • 弹出你的藏匿处。
  • 干得好。
  • 推送到远程。

如果将其应用于其他分支或远程，请记住更改“origin”和“master”。

21
投票

我通过放弃我的本地修改提交并在顶部添加新更改来解决它：

# 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
7
投票

我有同样的问题。

  • 意外修改了已推送的最后一次提交
  • 在本地做了很多改变，承诺了五次
  • 试图推，得到一个错误，恐慌，合并远程，得到了很多不是我的文件，推，失败等。

作为一个Git新手，我认为这是完整的FUBAR。

解决方案：有点像@bara建议+创建一个本地备份分支

# Rewind to commit just before the pushed-and-amended one.
# Replace <hash> with the needed hash.
# --soft means: leave all the changes there, so nothing is lost.
git reset --soft <hash>

# Create new branch, just for a backup, still having all changes in it.
# The branch was feature/1234, new one - feature/1234-gone-bad
git checkout -b feature/1234-gone-bad

# Commit all the changes (all the mess) not to lose it & not to carry around
git commit -a -m "feature/1234 backup"

# Switch back to the original branch
git checkout feature/1234

# Pull the from remote (named 'origin'), thus 'repairing' our main problem
git pull origin/feature/1234

# Now you have a clean-and-non-diverged branch and a backup of the local changes.
# Check the needed files from the backup branch
git checkout feature/1234-gone-bad -- the/path/to/file.php

也许这不是一个快速而干净的解决方案，我失去了我的历史（1次提交而不是5次），但它节省了一天的工作。

5
投票

如果您尚未将代码推送到远程分支（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

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

5
投票

如果您知道没有人撤消您未经修改的提交，请使用--force-with-lease的git push选项。

在TortoiseGit中，您可以在“推送...”选项“强制：可以丢弃”并检查“已知更改”下执行相同的操作。

Force (May discard known changes)允许远程存储库接受更安全的非快进推送。这可能导致远程存储库丢失提交;小心使用它。这可以防止丢失遥控器上其他人的未知更改。它检查服务器分支是否指向与远程跟踪分支相同的提交（已知更改）。如果是，则执行强制推动。否则将被拒绝。由于git没有远程跟踪标记，因此使用此选项无法覆盖标记。

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.