Why does Git want me to pull before I push?
I was setting up a new repository on GitHub and was trying to push to it but Git kept giving me an error saying:
error: failed to push some refs to…
Jenkins GitHub Organization pipeline 'checkout scm' fails on agent (slave/node) Set an environment variable in git bash Un-ignore a directory added to .gitignore How can you git add a new file without staging it? Problems with entering Git commit message with Vim Is there a way to tell how far Jenkins has gotten in cloning a Git repo?
I eventually tried pulling first and then pushing and that worked. But why?
4 Solutions collect form web for “Why does Git want me to pull before I push?”
You mentioned that you were creating a new repository.
While the answer’s and comments are also true, it is likely you’re the only person interacting with the repository. You were required to pull because you initialized the repository with a README on GitHub (this is likely the tutorial you followed).
If you did not initialize the repository with a README, meaning GitHub didn’t make a first commit of ‘README.md’, you would have a completely empty repository you can directly push to.
The reason why GitHub has that option is most likely to assist users who are starting a new project (such as yourself) to very easily get going after setting up a repository on GitHub by doing a pull/clone and having that initial commit in, allowing you to quickly add new files and push.
Additionally, by initializing a repository with a README, you’ll have a master branch ready to clone and start tracking files. While on a completely empty repository you will receive notifications from Git like:
warning: You appear to have cloned an empty repository.
Without initializing, you will also later have to push your first commits the first time explicitly to master with
git push origin master, as Git will politely tell you:
No refs in common and none specified; doing nothing. Perhaps you should specify a branch such as 'master'. Everything up-to-date
To summarize, it was that first commit (see your commits and you’ll see the first
README commit) that prevented you from pushing without pulling as your local repository is not in sync with the repository on GitHub.
That’s so that any parallel edits made by someone else and then checked in are brought into your development environment for merging and testing. In this way, the number of parallel, non-integrated changes is kept to a manageable minimum
In your case, GitHub has automatically created the first commit (often README.md and LICENCE files) and in order to push your commits, you must first pull (fetch and merge) GitHub’s commit.
When you pull, Git will fetch commits on origin and will try to fast-forward your local commits on top of them, doing the merge. After that you can push in this way, and you will not generate conflicts with other updates.