fatal: refusing to merge unrelated histories — your local repository and the remote each have their own first commit, so they share no history at all. The classic cause is creating the repository on GitHub with a README and also running git init locally. If both really are the same project, pull once with --allow-unrelated-histories, then push.

The fix is git pull origin main --allow-unrelated-histories. It creates one merge commit that joins the two histories, and after it git push -u origin main goes through.

The error

$ git push -u origin main
To ../remote.git
 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to '../remote.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. This is usually caused by another repository pushing to
hint: the same ref. If you want to integrate the remote changes, use
hint: 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
$ git pull origin main
From ../remote
 * branch            main       -> FETCH_HEAD
 * [new branch]      main       -> origin/main
fatal: refusing to merge unrelated histories

The push failed first; following its hint led to the real error. Exit code 128.

Why it happens

A merge starts from the newest commit both sides have in common and combines what changed since. Here there is none. The host repository began with its own Initial commit (the README), and git init plus a commit made Add home page, a second root commit with no parent. Git's manual says git merge refuses histories with no common ancestor by default, and that the override is for two projects that started independently; there is no config setting that turns the check off.

If you have no pull.rebase setting at all, the same pull stops one step earlier with fatal: Need to specify how to reconcile divergent branches.; git pull --no-rebase origin main then shows the error above. The Git for Windows install used here has pull.rebase=false in its system config, so it appeared straight away.

The fix

$ git pull origin main --allow-unrelated-histories
From ../remote
 * branch            main       -> FETCH_HEAD
Merge made by the 'ort' strategy.
 README.md | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

$ git log --oneline --graph --all
*   916c5ff Merge branch 'main' of ../remote
|\
| * e23ca2e Initial commit
* 317ba96 Add home page

$ git push -u origin main
branch 'main' set up to track 'origin/main'.
To ../remote.git
   e23ca2e..916c5ff  main -> main

The history now has two root commits (git rev-list --max-parents=0 HEAD listed both) joined by one merge commit, and the remote accepted it as a normal push. No existing commit changed.

Two things to know. If both sides have a file with the same name and different content, usually README.md, the pull stops with CONFLICT (add/add): Merge conflict in README.md; resolve it like any conflict, or back out with git merge --abort. And git pull --rebase origin main also worked without the flag: it replayed Add home page on top of the README commit, leaving one root and a straight line.

The flag is the wrong answer when you could simply have cloned. On a second host repository seeded the same way, git clone, a commit and a plain git push gave one root commit and no error at all.

How it was reproduced

Git for Windows 2.45.2 (git version 2.45.2.windows.1), run from Git Bash. A bare repository (git init --bare -b main) played GitHub, and a throwaway clone pushed a single Initial commit with a one-line README.md into it, standing in for a host that adds a README when it creates the repository. A separate git init -b main project committed index.html, added the bare repository as origin, and pushed. The machine's personal global config was replaced by an empty file throughout.

Frequently asked

What does 'refusing to merge unrelated histories' mean in Git?
The two branches you are merging have no commit in common, because each started from its own first commit. Git will not merge them unless you pass --allow-unrelated-histories.
Is git pull --allow-unrelated-histories safe?
Yes, when both histories belong to the same project, such as a README the host created and your local first commit. It adds one merge commit and changes no existing commit. A file with the same name but different content on both sides comes back as an add/add conflict to resolve.
How do I avoid unrelated histories when creating a GitHub repository?
Create the repository on the host empty, with no README, license or .gitignore, and push your local repository into it. Or create it with a README and clone it before you write any code.

More decoded errors in the Fixes category. Part 6 of the Git series, GitHub: Your Code in the Cloud, creates the GitHub repository with every checkbox unticked for exactly this reason, then pushes the local history into it.