Git push asks to fetch and merge but there is nothing to fethc or merge

Question

I have been trying to get familiar with Git, new to programming. However, every time I seem to want to push git "git push origin main", I get an error saying my local and remote branches have diverged.

I don't understand how this is possible is this is a brand new empty repository, when I try and do git fetch (as you can see on imagine) it works fine however there is nothing to merge or pull (the error message is merge:origin - not something we can merge").
How do I go about fixing this?

Oh also since this is just a test I tried git push -f as well to no avail I get :

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

    git push --set-upstream origin main

To have this happen automatically for branches without a tracking
upstream, see 'push.autoSetupRemote' in 'git help config'.

I also tried git rebase, fetch and merge.
Although as I said this shouldn't be the problem, the git repo is brand new and there are no change to merge

Update

So, pro, was able to fix the problem, con, not sure how, if I happen to figure it out in more detail or have more of an understanding I'll edit this question and add a more detailed explanation just in case anyone else happens to run into this issue.
However, all of these answer were a great starting point so I suggest you give that a try too if no update is made.

Answer 1

Git has a steep learning curve, like climbing a mountain all at once in a few hours or days. This is both the bad news (it's a lot of work!) and the good news (you're on top of a mountain in just a few hours or days!).

When you use git init to create a new repository (git init has a completely different function when you use it on an existing repository), you get a new, empty repository with no commits and no branches. Nonetheless, you're still "on" some branch. You might wonder how you can be on a branch that doesn't exist. Well, that's one of the reasons Git has such a steep learning curve. (The fact that git init does two almost-completely different things—create a new repository, or "reinitialize" an existing one, in which case, usually nothing at all happens—is another of those reasons.)

When you're in this funny "on a branch that does not exist" state, the next commit you make will create the branch. So it's your initial commit that actually creates the branch. That's why Git said:

[main (root-commit) d09db1a] test

The (root-commit) is the clue that this just created the branch; the main part is the name of the branch it just created, and d09db1a is the hash ID or OID of the new commit (abbreviated, though: the actual hash IDs are even longer and quite random-looking).

Creating the branch takes you out of the weird state. For this reason, GitHub and other hosting sites will often create a new repository for you and immediately create one commit so that the new repository can have a branch. You can clone a totally-empty repository, one with no commits and no branches at all, but the effect is as weird as the fact that you're on a branch when there is no branch. 🤔 This is why GitHub really like to make your first commit for you.

The problem in this case is that in Git, the commits are the history: history is nothing more or less than the set of commits in the repository. Commits normally have parent/child relationships: the very first commit ever is the root commit—that's the phrase we just saw again—and then every commit after that is a child or grand-child or great-grand-child or great-great-... etc of that root commit.

But when you let GitHub create the first commit, and then you also create the first commit, well, now you have two first commits that aren't related. And, alas, Git doesn't like to "marry" (merge) unrelated commits. (Perhaps the "must marry your cousin" thing also explains some of Git's weirdness. 😀)

This is why, as VonC says, if you plan to make the first commit yourself, locally, you shouldn't let GitHub make the first commit too. GitHub give you some clicky check-boxes (well, radio buttons) on the web page when you go to create a new repository on GitHub.

Anyway, this gets you on to the next parts of the steep learning curve. A relatively new one of these is now the whole master vs main thing. When you create that first commit, that creates the branch you were on, so that it now exists. The name that this creates is the one you chose at git init time, using the -b option (see the git init documentation). But you didn't use -b, so you got some default. The default was master. In some versions and distributions of Git, the default still is master. In other versions, the default is now main. This situation has been going on for a few years now. It's not clear if it will ever resolve completely (there are still people out there using Git 1.7 and 1.8 and those are more than ten years old—well, 1.8 is just under 10 years old right now, but that won't last).

Two down, many to go: you've hit two oddities already (i.e., why a truly-empty repository is weird and slightly complicated, and main-vs-master). You have a lot left to go. "Upstreams" are one of these, but they're not as tricky as the whole idea of "repository clones" in the first place. The thing to remember here is that Git is really about commits, and commits are really found by their hash IDs. Things like branch names are mostly for humans, not so much for Git itself.

Answer 2

First, there is no master branch. Not in your local repository, or your remote one.

Second, a git merge origin/main would merge the history of the fetched remote main branch to your local one, allowing you a git push -u origin main after that. (see "Why do I need to explicitly push a new branch?", and "Why do I need to do --set-upstream all the time?")

"brand new repository": make sure that, when you create your GitHub repository, you don't add a README or LICENSE on creation: that would make a remote history (of one commit) which would explain why your first push fails.

Answer 3

When you run git init you are initialising a new git project, you’ve later set the upstream to an existing git project which means you now have 2 initialised git projects.

You are then trying to push the newly initialised to an existing one but this is failing as the existing upstream commits do not match the newly initialised local one and that causes the issue.

You should git clone an existing upstream repo otherwise you will have to pull the other branches commits into your newly created repo which I wouldn’t recommend as it can cause a bundle of issues.

From my understanding What you would be trying to do is fork a project which is an independent repository of the same project but is not linked to old repository.

This is a good read on the issue:

https://www.theserverside.com/answer/Git-fork-vs-clone-Whats-the-difference?amp=1