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

时间:2021-12-08 07:24:00

When I've worked a bit with my source code, I did my usual thing commit and then I pushed to a remote repository. But then I noticed I forgot to organize my imports in the source code. So I do the amend command to replace the previous commit:

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

> git commit --amend

Unfortunately the commit can't be pushed back to the repository. It is rejected like this:

不幸的是,提交不能被推回到存储库。这被拒绝了:

> 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/'

What should I do? (I can access the remote repository.)

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

13 个解决方案

#1


431  

I actually once pushed with --force and .git repository and got scolded by Linus BIG TIME. In general this will create a lot of problems for other people. A simple answer is "Don't do it".

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

I see others gave the recipe for doing so anyway, so I won't repeat them here. But here is a tip to recover from the situation after you have pushed out the amended commit with --force (or +master).

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

  1. Use git reflog to find the old commit that you amended (call it old, and we'll call the new commit you created by amending new).
  2. 使用git reflog查找您修改的旧提交(称之为旧提交,我们将调用您通过修改new创建的新提交)。

  3. Create a merge between old and new, recording the tree of new, like git checkout new && git merge -s ours old.
  4. 在新旧之间创建一个合并,记录新的树,比如git checkout new && git merge -s our old。

  5. Merge that to your master with git merge master
  6. 使用git merge master将其合并到您的主服务器

  7. Update your master with the result with git push . HEAD:master
  8. 使用git push通过结果更新master。校长

  9. Push the result out.
  10. 推出结果。

Then people who were unfortunate enough to have based their work on the commit you obliterated by amending and forcing a push will see the resulting merge will see that you favor new over old. Their later merges will not see the conflicts between old and new that resulted from your amending, so they do not have to suffer.

然后,那些不幸的人将你的工作建立在你通过修改和强制推动而消除的提交上的工作将会看到由此产生的合并会看到你喜欢新旧的。他们后来的合并将不会看到你修改后产生的新旧冲突,所以他们不必受苦。

#2


244  

You are seeing a Git safety feature. Git refuses to update the remote branch with your branch, because your branch's head commit is not a direct descendent of the current head commit of the branch that you are pushing to.

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

If this were not the case, then two people pushing to the same repository at about the same time would not know that there was a new commit coming in at the same time and whoever pushed last would lose the work of the previous pusher without either of them realising this.

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

If you know that you are the only person pushing and you want to push an amended commit or push a commit that winds back the branch, you can 'force' Git to update the remote branch by using the -f switch.

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

git push -f origin master

Even this may not work as Git allows remote repositories to refuse non-fastforward pushes at the far end by using the configuration variable receive.denynonfastforwards. If this is the case the rejection reason will look like this (note the 'remote rejected' part):

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

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

To get around this, you either need to change the remote repository's configuration or as a dirty hack you can delete and recreate the branch thus:

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

git push origin :master
git push origin master

In general the last parameter to git push uses the format <local_ref>:<remote_ref>, where local_ref is the name of the branch on the local repository and remote_ref is the name of the branch on the remote repository. This command pair uses two shorthands. :master has a null local_ref which means push a null branch to the remote side master, i.e. delete the remote branch. A branch name with no : means push the local branch with the given name to the remote branch with the same name. master in this situation is short for master:master.

通常,git push的最后一个参数使用格式 : ,其中local_ref是本地存储库上分支的名称,remote_ref是远程存储库上分支的名称。此命令对使用两个shorthands。 :master具有null local_ref,这意味着将空分支推送到远程主服务器,即删除远程分支。带有no的分支名称:表示将具有给定名称的本地分支推送到具有相同名称的远程分支。在这种情况下掌握主人的简称:主人。

#3


194  

Quick rant: The fact that no one has posted the simple answer here demonstrates the desperate user-hostility exhibited by the Git CLI.

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

Anyway, the "obvious" way to do this, assuming you haven't tried to force the push, is to pull first. This pulls the change that you amended (and so no longer have) so that you have it again.

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

Once you have resolved any conflicts, you can push again.

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

So:

git pull

If you get errors in pull, maybe something is wrong in your local repository configuration (I had a wrong ref in the .git/config branch section).

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

And after

git push

Maybe you will get an extra commit with the subject telling about a "Trivial merge".

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

#4


94  

Short answer: Don't push amended commits to a public repo.

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

Long answer: A few Git commands, like git commit --amend and git rebase, actually rewrite the history graph. This is fine as long as you haven't published your changes, but once you do, you really shouldn't be mucking around with the history, because if someone already got your changes, then when they try to pull again, it might fail. Instead of amending a commit, you should just make a new commit with the changes.

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

However, if you really, really want to push an amended commit, you can do so like this:

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

$ git push origin +master:master

The leading + sign will force the push to occur, even if it doesn't result in a "fast-forward" commit. (A fast-forward commit occurs when the changes you are pushing are a direct descendant of the changes already in the public repo.)

前导+符号将强制推送发生,即使它不会导致“快进”提交。 (当您推送的更改是公共存储库中已有的更改的直接后代时,会发生快进提交。)

#5


38  

Here is a very simple and clean way to push your changes after you have already made a commit --amend:

在您完成提交后,这是一种非常简单而干净的方式来推送您的更改--amend:

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

Which does the following:

以下是:

  • Reset branch head to parent commit.
  • 将分支头重置为父提交。

  • Stash this last commit.
  • 存放最后一次提交。

  • Force push to remote. The remote now doesn't have the last commit.
  • 强行推送到远程。远程现在没有最后一次提交。

  • Pop your stash.
  • 弹出你的藏匿处。

  • Commit cleanly.
  • Push to remote.
  • 推送到远程。

Remember to change "origin" and "master" if applying this to a different branch or remote.

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

#6


21  

I have solved it by discarding my local amended commit and adding the new changes on top:

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

# 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


7  

I had the same problem.

我有同样的问题。

  • Accidentally amended the last commit that was already pushed
  • 意外修改了已推送的最后一次提交

  • Done a lot of changes locally, committed some five times
  • 在本地完成了很多变化,承诺了五次

  • Tried to push, got an error, panicked, merged remote, got a lot of not-my-files, pushed, failed, etc.
  • 试图推,得到一个错误,恐慌,合并远程,得到了很多不是我的文件,推,失败等。

As a Git-newbie, I thought it was complete FUBAR.

作为Git-newbie,我认为这是完整的FUBAR。

Solution: Somewhat like @bara suggested + created a local backup branch

解决方案:有点像@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

Maybe it's not a fast and clean solution, and I lost my history (1 commit instead of 5), but it saved a day's work.

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

#8


4  

If you know nobody has pulled your un-amended commit, use the --force-with-lease option of git push.

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

In TortoiseGit, you can do the same thing under "Push..." options "Force: May discard" and checking "known changes".

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

Force (May discard known changes) allows the remote repository to accept a safer non-fast-forward push. This can cause the remote repository to lose commits; use it with care. This can prevent from losing unknown changes from other people on the remote. It checks if the server branch points to the same commit as the remote-tracking branch (known changes). If yes, a force push will be performed. Otherwise it will be rejected. Since git does not have remote-tracking tags, tags cannot be overwritten using this option.

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

#9


3  

If you have not pushed the code to your remote branch (GitHub/Bitbucket) you can change the commit message on the command line as below.

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

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

If you're working on a specific branch, do this:

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

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

If you've already pushed the code with a wrong message then you need to be careful when changing the message. i.e after you change the commit message and try pushing it again you end up with having issues. To make it smooth follow the following steps.

如果您已经使用错误的消息推送了代码,则在更改消息时需要小心。即在您更改提交消息并尝试再次推送之后,最终会出现问题。要使其顺利进行,请按照以下步骤操作。

Please read the entire answer before doing it

请在完成之前阅读完整的答案

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

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

Important note: When you use the force push directly you might end up with code issues that other developers are working on the same branch. So to avoid those conflicts you need to pull the code from your branch before making the force push:

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

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

This is the best practice when changing the commit message, if it was already pushed.

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

#10


2  

Here is a very simple and clean way to push your changes after you have already made a git add "your files" and git commit --amend:

这是一个非常简单和干净的方法来推动您的更改后,你已经做了一个git添加“你的文件”和git commit --amend:

git push origin master -f

or:

git push origin master --force

#11


2  

You are getting this error because the Git remote already has these commit files. You have to force push the branch for this to work:

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

git push -f origin branch_name

Also make sure you pull the code from remote as someone else on your team might have pushed to the same branch.

还要确保从团队中的其他人推送到同一分支机构时从远程提取代码。

git pull origin branch_name

This is one of the cases where we have to force push the commit to remote.

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

#12


1  

I had to fix this problem with pulling from the remote repo and deal with the merge conflicts that arose, commit and then push. But I feel like there is a better way.

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

#13


1  

I just kept doing what Git told me to do. So:

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

  • Can't push because of amended commit.
  • 因修改提交而无法推送。

  • I do a pull as suggested.
  • 我建议拉一下。

  • Merge fails. so I fix it manually.
  • 合并失败。所以我手动修复它。

  • Create a new commit (labeled "merge") and push it.
  • 创建一个新的提交(标记为“merge”)并推送它。

  • It seems to work!
  • 它似乎工作!

Note: The amended commit was the latest one.

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

#1


431  

I actually once pushed with --force and .git repository and got scolded by Linus BIG TIME. In general this will create a lot of problems for other people. A simple answer is "Don't do it".

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

I see others gave the recipe for doing so anyway, so I won't repeat them here. But here is a tip to recover from the situation after you have pushed out the amended commit with --force (or +master).

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

  1. Use git reflog to find the old commit that you amended (call it old, and we'll call the new commit you created by amending new).
  2. 使用git reflog查找您修改的旧提交(称之为旧提交,我们将调用您通过修改new创建的新提交)。

  3. Create a merge between old and new, recording the tree of new, like git checkout new && git merge -s ours old.
  4. 在新旧之间创建一个合并,记录新的树,比如git checkout new && git merge -s our old。

  5. Merge that to your master with git merge master
  6. 使用git merge master将其合并到您的主服务器

  7. Update your master with the result with git push . HEAD:master
  8. 使用git push通过结果更新master。校长

  9. Push the result out.
  10. 推出结果。

Then people who were unfortunate enough to have based their work on the commit you obliterated by amending and forcing a push will see the resulting merge will see that you favor new over old. Their later merges will not see the conflicts between old and new that resulted from your amending, so they do not have to suffer.

然后,那些不幸的人将你的工作建立在你通过修改和强制推动而消除的提交上的工作将会看到由此产生的合并会看到你喜欢新旧的。他们后来的合并将不会看到你修改后产生的新旧冲突,所以他们不必受苦。

#2


244  

You are seeing a Git safety feature. Git refuses to update the remote branch with your branch, because your branch's head commit is not a direct descendent of the current head commit of the branch that you are pushing to.

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

If this were not the case, then two people pushing to the same repository at about the same time would not know that there was a new commit coming in at the same time and whoever pushed last would lose the work of the previous pusher without either of them realising this.

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

If you know that you are the only person pushing and you want to push an amended commit or push a commit that winds back the branch, you can 'force' Git to update the remote branch by using the -f switch.

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

git push -f origin master

Even this may not work as Git allows remote repositories to refuse non-fastforward pushes at the far end by using the configuration variable receive.denynonfastforwards. If this is the case the rejection reason will look like this (note the 'remote rejected' part):

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

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

To get around this, you either need to change the remote repository's configuration or as a dirty hack you can delete and recreate the branch thus:

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

git push origin :master
git push origin master

In general the last parameter to git push uses the format <local_ref>:<remote_ref>, where local_ref is the name of the branch on the local repository and remote_ref is the name of the branch on the remote repository. This command pair uses two shorthands. :master has a null local_ref which means push a null branch to the remote side master, i.e. delete the remote branch. A branch name with no : means push the local branch with the given name to the remote branch with the same name. master in this situation is short for master:master.

通常,git push的最后一个参数使用格式 : ,其中local_ref是本地存储库上分支的名称,remote_ref是远程存储库上分支的名称。此命令对使用两个shorthands。 :master具有null local_ref,这意味着将空分支推送到远程主服务器,即删除远程分支。带有no的分支名称:表示将具有给定名称的本地分支推送到具有相同名称的远程分支。在这种情况下掌握主人的简称:主人。

#3


194  

Quick rant: The fact that no one has posted the simple answer here demonstrates the desperate user-hostility exhibited by the Git CLI.

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

Anyway, the "obvious" way to do this, assuming you haven't tried to force the push, is to pull first. This pulls the change that you amended (and so no longer have) so that you have it again.

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

Once you have resolved any conflicts, you can push again.

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

So:

git pull

If you get errors in pull, maybe something is wrong in your local repository configuration (I had a wrong ref in the .git/config branch section).

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

And after

git push

Maybe you will get an extra commit with the subject telling about a "Trivial merge".

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

#4


94  

Short answer: Don't push amended commits to a public repo.

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

Long answer: A few Git commands, like git commit --amend and git rebase, actually rewrite the history graph. This is fine as long as you haven't published your changes, but once you do, you really shouldn't be mucking around with the history, because if someone already got your changes, then when they try to pull again, it might fail. Instead of amending a commit, you should just make a new commit with the changes.

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

However, if you really, really want to push an amended commit, you can do so like this:

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

$ git push origin +master:master

The leading + sign will force the push to occur, even if it doesn't result in a "fast-forward" commit. (A fast-forward commit occurs when the changes you are pushing are a direct descendant of the changes already in the public repo.)

前导+符号将强制推送发生,即使它不会导致“快进”提交。 (当您推送的更改是公共存储库中已有的更改的直接后代时,会发生快进提交。)

#5


38  

Here is a very simple and clean way to push your changes after you have already made a commit --amend:

在您完成提交后,这是一种非常简单而干净的方式来推送您的更改--amend:

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

Which does the following:

以下是:

  • Reset branch head to parent commit.
  • 将分支头重置为父提交。

  • Stash this last commit.
  • 存放最后一次提交。

  • Force push to remote. The remote now doesn't have the last commit.
  • 强行推送到远程。远程现在没有最后一次提交。

  • Pop your stash.
  • 弹出你的藏匿处。

  • Commit cleanly.
  • Push to remote.
  • 推送到远程。

Remember to change "origin" and "master" if applying this to a different branch or remote.

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

#6


21  

I have solved it by discarding my local amended commit and adding the new changes on top:

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

# 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


7  

I had the same problem.

我有同样的问题。

  • Accidentally amended the last commit that was already pushed
  • 意外修改了已推送的最后一次提交

  • Done a lot of changes locally, committed some five times
  • 在本地完成了很多变化,承诺了五次

  • Tried to push, got an error, panicked, merged remote, got a lot of not-my-files, pushed, failed, etc.
  • 试图推,得到一个错误,恐慌,合并远程,得到了很多不是我的文件,推,失败等。

As a Git-newbie, I thought it was complete FUBAR.

作为Git-newbie,我认为这是完整的FUBAR。

Solution: Somewhat like @bara suggested + created a local backup branch

解决方案:有点像@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

Maybe it's not a fast and clean solution, and I lost my history (1 commit instead of 5), but it saved a day's work.

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

#8


4  

If you know nobody has pulled your un-amended commit, use the --force-with-lease option of git push.

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

In TortoiseGit, you can do the same thing under "Push..." options "Force: May discard" and checking "known changes".

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

Force (May discard known changes) allows the remote repository to accept a safer non-fast-forward push. This can cause the remote repository to lose commits; use it with care. This can prevent from losing unknown changes from other people on the remote. It checks if the server branch points to the same commit as the remote-tracking branch (known changes). If yes, a force push will be performed. Otherwise it will be rejected. Since git does not have remote-tracking tags, tags cannot be overwritten using this option.

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

#9


3  

If you have not pushed the code to your remote branch (GitHub/Bitbucket) you can change the commit message on the command line as below.

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

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

If you're working on a specific branch, do this:

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

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

If you've already pushed the code with a wrong message then you need to be careful when changing the message. i.e after you change the commit message and try pushing it again you end up with having issues. To make it smooth follow the following steps.

如果您已经使用错误的消息推送了代码,则在更改消息时需要小心。即在您更改提交消息并尝试再次推送之后,最终会出现问题。要使其顺利进行,请按照以下步骤操作。

Please read the entire answer before doing it

请在完成之前阅读完整的答案

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

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

Important note: When you use the force push directly you might end up with code issues that other developers are working on the same branch. So to avoid those conflicts you need to pull the code from your branch before making the force push:

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

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

This is the best practice when changing the commit message, if it was already pushed.

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

#10


2  

Here is a very simple and clean way to push your changes after you have already made a git add "your files" and git commit --amend:

这是一个非常简单和干净的方法来推动您的更改后,你已经做了一个git添加“你的文件”和git commit --amend:

git push origin master -f

or:

git push origin master --force

#11


2  

You are getting this error because the Git remote already has these commit files. You have to force push the branch for this to work:

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

git push -f origin branch_name

Also make sure you pull the code from remote as someone else on your team might have pushed to the same branch.

还要确保从团队中的其他人推送到同一分支机构时从远程提取代码。

git pull origin branch_name

This is one of the cases where we have to force push the commit to remote.

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

#12


1  

I had to fix this problem with pulling from the remote repo and deal with the merge conflicts that arose, commit and then push. But I feel like there is a better way.

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

#13


1  

I just kept doing what Git told me to do. So:

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

  • Can't push because of amended commit.
  • 因修改提交而无法推送。

  • I do a pull as suggested.
  • 我建议拉一下。

  • Merge fails. so I fix it manually.
  • 合并失败。所以我手动修复它。

  • Create a new commit (labeled "merge") and push it.
  • 创建一个新的提交(标记为“merge”)并推送它。

  • It seems to work!
  • 它似乎工作!

Note: The amended commit was the latest one.

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