(Note: starting Oct. 2020, any new repository is created with the default branch main, not master. And you can rename existing repository default branch from master to main.
The rest of this 2014 answer has been updated to use «main«)
(The following assumes github.com itself is not down, as eri0o points out in the comments: see www.githubstatus.com to be sure)
If the GitHub repo has seen new commits pushed to it, while you were working locally, I would advise using:
git pull --rebase
git push
The full syntax is:
git pull --rebase origin main
git push origin main
With Git 2.6+ (Sept. 2015), after having done (once)
git config --global pull.rebase true
git config --global rebase.autoStash true
A simple git pull would be enough.
(Note: with Git 2.27 Q2 2020, a merge.autostash is also available for your regular pull, without rebase)
That way, you would replay (the --rebase part) your local commits on top of the newly updated origin/main (or origin/yourBranch: git pull origin yourBranch).
See a more complete example in the chapter 6 Pull with rebase of the Git Pocket Book.
I would recommend a:
# add and commit first
#
git push -u origin main
# Or git 2.37 Q2 2022+
git config --global push.autoSetupRemote true
git push
That would establish a tracking relationship between your local main branch and its upstream branch.
After that, any future push for that branch can be done with a simple:
git push
Again, with Git 2.37+ and its global option push.autoSetupRemote, a simple git push even for the first one would do the same (I.e: establishing a tracking relationship between your local main branch and its upstream branch origin/main).
See «Why do I need to explicitly push a new branch?».
Since the OP already reset and redone its commit on top of origin/main:
git reset --mixed origin/main
git add .
git commit -m "This is a new commit for what I originally planned to be amended"
git push origin main
There is no need to pull --rebase.
Note: git reset --mixed origin/main can also be written git reset origin/main, since the --mixed option is the default one when using git reset.
Sometimes, Git can’t make your change to a remote repository without losing commits. When this happens, your push is refused.
If another person has pushed to the same branch as you, Git won’t be able to push your changes:
$ git push origin main
> To https://github.com/USERNAME/REPOSITORY.git
> ! [rejected] main -> main (non-fast-forward)
> error: failed to push some refs to 'https://github.com/USERNAME/REPOSITORY.git'
> To prevent you from losing history, non-fast-forward updates were rejected
> Merge the remote changes (e.g. 'git pull') before pushing again. See the
> 'Note about fast-forwards' section of 'git push --help' for details.You can fix this by fetching and merging the changes made on the remote branch with the changes that you have made locally:
$ git fetch origin
# Fetches updates made to an online repository
$ git merge origin YOUR_BRANCH_NAME
# Merges updates made online with your local workOr, you can simply use git pull to perform both commands at once:
$ git pull origin YOUR_BRANCH_NAME
# Grabs online updates and merges them with your local workYou are here: Home / Solution / Git failed to push some refs
At some point when pushing your code to a remote server (e.g. GitHub, Bitbucket, GitLab) you’re going to see an error like the following
To github.com:salcode/myrepo.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'git@github.com:salcode/myrepo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
The important part here is “Updates were rejected because the tip of your current branch is behind its remote counterpart.”
How did this happen?
Typically, someone else has pushed code to your remote server that you do not yet have.
What you wanted to happen
Imagine the commits for both your local master branch and the remote server origin/master branch look something like
master origin/master
cem32k cem32k
b4d2o1 b4d2o1
abc123 abc123
(If viewing your Git branch as a list of commits like this seems unfamiliar, I suggest checking out my post on How to Improve Git Log)
Once you’re comfortable with the commits above, you add a new commit (dg34mp) to your local (master) branch.
master origin/master
dg34mp
cem32k cem32k
b4d2o1 b4d2o1
abc123 abc123
Then you use
git push
and the remote server origin/master is brought up-to-date.
master origin/master
dg34mp dg34mp
cem32k cem32k
b4d2o1 b4d2o1
abc123 abc123
This is what we wanted to happen.
What really happened
While you were creating your new commit (dg34mp) on your local (master) branch, someone else added their own commit (zyx911) to the remote server
master origin/master
dg34mp zyx911
cem32k cem32k
b4d2o1 b4d2o1
abc123 abc123
Now when you use
git push
Git says, “Whoa, hold on! I can’t add the dg34mp commit because there is an extra commit on the remote server we haven’t taken into account!” (a.k.a. I don’t know how to handle zyx911, “failed to push some refs”).
What do we do?
First, we make a backup copy of our master branch, in case something goes wrong. (This isn’t strictly necessary because of git reflog, but I find making a backup branch quicker and involving less thought). Once we make this backup branch we’re going to ignore it and ultimately when we’re done with this process we can delete it.
git branch bkup
Now, we rebase our master branch with the remote branch origin/master.
git rebase origin/master
This replaces our local master branch with the remote origin/master and then adds our new commit (dg34mp) on top.
master origin/master
dg34mp
zyx911 zyx911
cem32k cem32k
b4d2o1 b4d2o1
abc123 abc123
Now we can push our changes to the remote server (origin/master)
git push
and there is no problem because we are simply adding our new commit (dg34mp) to the remote branch.
Photo Credit
Marina del Castell
Reader Interactions
|
fatal: No such remote ‘origin’ |
|
fatal: No such remote ‘origin’
fatal: No such remote ‘origin’
Скорее всего Вы пытаетесь выполнить
$ git remote set-url origin https://github.com/name/project.git
Попробуйте сперва выполнить
$ git remote add origin https://github.com/name/project.git
2
To https://github.com/YourName/yourproject.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to ‘https://github.com/YourName/yourproject.git’
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: ‘git pull …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push —help’ for details.
Скорее всего Вы пытаетесь выполнить
git push origin master
в новом репозитории.
При этом, когда
Вы создавали удалённый репозиторий на github Вы отметили опцию initialize with readme file.
Таким образом на удалённом репозитории файл
README.md
есть, а на локальном нет. Git не
понимает как такое могло произойти и предполагает, что на удалённый репозиторий кто-то (возможно Вы)
добавил что-то неотслеженное локальным репозиторием.
Первым делом попробуйте
$ git pull origin master
$ git push origin master
Git скачает файл
README.md
с удалённого репозитория и затем можно будет спокойно пушить
Если сделать pull не получилось, например, возникла ошибка
From https://github.com/andreiolegovichru/heiheiru
* branch master -> FETCH_HEAD
fatal: refusing to merge unrelated histories
Попробуйте
$ git pull —allow-unrelated-histories origin master
$ git push origin master
ERROR: Permission to AndreiOlegovich/qa-demo-project.git denied to andreiolegovichru.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Возможная причина — git не видит ваш ключ. Либо ваш ключ уже используется для другого удалённого
хранилища.
Решить можно удалив стандарный ключ id_rsa.pub создать новую пару и добавить на удалённое хранилище.
Если этот способ не подходит — нужно настроить config.