1

I have a weird problem. I have done the following locally:

git init
git remote add [git repository]
git pull origin master

it worked fine Now when I needed to add some changes and do a push it gave me this error: 

fatal: The current branch master has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin master

I did as it said, git push --set-upstream..... and it threw me this error: 

To [git repo]
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to '[git repo]'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Now this couldn't have happened since I am the only one working on it and I did a pull before making changes locally.

EDIT: Thank you guys, I did delete a file from the remote repo after the pull. I did a pull again, made the changes again and pushed without a problem.

Spirit_Scarlet
  • 327
  • 1
  • 4
  • 17
  • 1
    can you check the putty key? – Ragavan Rajan Sep 13 '18 at 20:16
  • 1
    What protocol are you using to access the remote git repository? (e.g. `git://`, `http://`, `https://` etc.) Also, you're 100% certain that you didn't change something in the remote repository between your `git pull` and `git push`? (e.g. if you're using a web hosted repository like GitHub, you could have made changes to the remote repository in your browser.) – 3D1T0R Sep 13 '18 at 20:19
  • 3
    Try making a fresh clone of the remote repo in a new working directory. Then you can easily inspect the state of the remote repo and find out what the differences are. Otherewise if you are shure you don't destroy anything valuable on the remote, you can just say `git push -f`. – Adrian W Sep 13 '18 at 20:19

2 Answers2

1

Making the assumption that you want to push back to the master branch of the remote repository and that there are no merge conflicts, etc., try:

git push -u origin master
Matt Runion
  • 1,031
  • 7
  • 13
  • This didn't work either. The problem was that I had deleted a file from the remote repo and it didn't let me push cuz they were different. – Spirit_Scarlet Sep 13 '18 at 20:26
1

What's happening here is that git thinks the local repository's history isn't the same as the the remote repository's history. If you dig into how git actually works, it's pretty unlikely that it's wrong, so my guess would be that you've made a change on the remote repository since you ran that last git pull command.
This quote confirms this:

EDIT: Thank you guys, I did delete a file from the remote repo after the pull. I did a pull again, made the changes again and pushed without a problem.

Since you now know what the cause was, you realize that you can avoid it by only making local changes when you know the remote hasn't been changed, but that doesn't sound like a very good workflow, especially if multiple people are working on a repository. Besides, one of the strengths of git is supposed to be that multiple people can work on the same repository at the same time and all push to the same remote repository.

Let's look at what commands you have available to you that can be used to deal with this better in the future:

fetch

You can always safely fetch the changes from the remote repository without affecting your working copy or local branches. This will download the new history from the remote repository into what's known as a 'tracking branch', but it doesn't apply it to any of your local branches, and it doesn't touch your 'working copy'.

merge

A merge will try to apply the changes in another branch to the head of the branch you're on. It can be used between local branches, or to merge changes from tracking branches into a local branch. However it does so using a 'merge commit', allowing for non-linear history. Git has no issue with this, and in small doses humans aren't usually too bothered by it either:
Simple non-linear git history with a merge commit
The more you do it though, the more complex the history becomes, and mere humans can have some difficulty keeping track of things as the complexity increases:
An example of messy history in a git repository caused by excessive merging without rebasing

pull

This is really just a fetch followed by a merge: Visual representation of a pull command where fetch updates the tracking branch, then merge applies those changes to the local branch.

rebase

This is a form of rewriting history. Basically you're merging the changes from one branch into another, however unlike a regular merge, you don't just tie the two branches together and call it good, instead you take off the changes you've made on one branch after the two branches split, apply the changes from the other branch, then reapply the changes that you took off, leaving a nice, linear history.
Before:
This shows two branches which have not been merged or rebased.
After:
This shows the new repository history after a rebase.

pull --rebase

This (like a regular pull) uses fetch to get the remote changes, but instead of following up with a merge, it does a rebase, so you can have the ease of using only having to run one command and also have a nice, linear history when you look back on what you've done.

[All images in this answer are also a link to where I got them from.]

3D1T0R
  • 1,050
  • 7
  • 17