When I work with my source code, I do my usual submissions and push them to a remote repository.But then I noticed that I forgot to organize my imports in the source code.So I made a modification command to replace my previous submission:

> git commit --amend

Unfortunately, submissions cannot be pushed back to the repository.This was rejected:

> 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.)

#1st floor

I resolve it by discarding my local modification submission and adding new changes at the 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

#2nd floor

Quick roar: No one here has posted a simple answer that demonstrates the desperate user hostility Git CLI has shown.

In any case, assuming you haven't tried to push hard, the obvious approach is to pull first.This will pull your modified changes (and therefore no longer have them) so that you can use them again.

After any conflict is resolved, you can push again.

So:

git pull

If you make a mistake in pull, there may be a problem with your local repository configuration (I have an incorrect reference in the.git / config branch).

after

git push

Perhaps you'll get extra submissions on the subject of Trivial Merge.

#3rd floor

I have the same question.

• Unexpected modification to the last submitted push
• Many changes have been made locally, and five promises have been made
• Trying to push, get an error, panic, merge remote, get a lot of files that are not mine, push, fail, etc.

As Git-newbie, I think it's complete FUBAR .

Solution: A bit like @bara recommendation + create a local backup branch

# 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 quick and clean solution. I lost my history (one submission instead of five), but it saved a day's work.

#4th floor

I have to solve this problem by extracting and resolving merge conflicts that occur from remote repositories, submitting and pushing.But I think there's a better way.

#5th floor

Short answer: Do not push modified submissions to public repurchase.

The answer is long: some Git commands, such as git commit--amend and git rebase, actually rewrite the history map.It's good as long as you don't publish your changes, but once you do, you really shouldn't wander through the history, because if someone has changed you, it may fail when they try to pull again.You should only use changes to make new submissions, not modify them.

However, if you really want to push a modified submission, you can do so:

$ git push origin +master:master

A leading + symbol will force a push to occur even if it does not result in a Fast Forward commit.(Fast forward commits occur when the changes you push are direct descendants of changes already in the public repository.)