🔀 Reading Git Error Messages

Git is preventing you from overwriting history you haven't seen yet.

A "fetch first" rejection (a non-fast-forward push) means someone else pushed to main after your last git pull/git fetch. Your local branch and the remote branch have diverged. If Git allowed the push anyway, the remote's newer commits would be lost (or hidden) from the branch pointer.

The fix — in order of what's usually correct:

• git pull origin main (merges the remote changes in, creating a merge commit if needed), then push again
• git pull --rebase origin main to replay your commits on top of the remote ones, keeping history linear
• Never use git push --force here on a shared branch like main — that discards the other person's commits entirely instead of integrating them

How to describe this to a colleague: "My push got rejected — someone else pushed to main since I last pulled, I just need to pull and re-push." This is one of the most common early-career Git moments; explaining it calmly (rather than force-pushing out of frustration) is exactly the professional communication this reflects.

A content conflict — two branches edited the same lines differently, and Git needs a human decision.

"Auto-merging src/cart.js" shows Git successfully merged other files automatically first. The conflict is specific to src/cart.js, where both branches changed overlapping content. Git inserts conflict markers directly into the file: <<<<<<< HEAD ... ======= ... >>>>>>> feature/checkout.

Resolution steps:

1. Open the file, find the conflict markers
2. Decide which lines to keep (yours, theirs, or a combination) and remove the markers
3. git add src/cart.js to mark it resolved
4. git commit to complete the merge

Important: the merge is not "failed and rolled back" — it's paused, waiting on you. git status at this point shows the file under "Unmerged paths".

How to describe this to a colleague: "There's a merge conflict in cart.js — looks like we both touched the discount calculation, I'll sort it out and ping you if I'm not sure which version is right." Distinguishing content conflict from a hard failure is exactly the vocabulary that prevents unnecessary panic in a team channel.

Two histories with no shared starting point — usually from initialising a repo twice.

Every commit in Git links back to a parent commit, forming a chain to an initial commit. "Unrelated histories" means the local and remote commit chains never intersect — there's no common ancestor. This commonly happens when: someone runs git init and commits locally, then creates a GitHub repo separately (perhaps with an auto-generated README) and tries to pull/push between them, or a repository was re-created from scratch under the same name.

Git added this safeguard because merging unrelated histories is rare in normal workflows and is more often a sign that the wrong remote was configured, so it asks for explicit confirmation.

The fix (once you've confirmed this is intentional):
git pull origin main --allow-unrelated-histories

This will likely produce conflicts to resolve (e.g. two different README files) since both histories may have overlapping filenames with different content.

How to describe this to a colleague: "Git's refusing to merge because these two repos don't share any history — I think we accidentally created the GitHub repo with its own initial commit instead of pushing our existing one into it."

Git refuses to discard uncommitted work — you must commit or stash it first.

Checking out a different branch replaces the working directory's files with that branch's version of them. If src/config.js on main differs from your currently-uncommitted local edits, switching branches would overwrite your changes with no way to get them back — so Git blocks the checkout entirely rather than risk silent data loss.

Two correct paths:

• Commit the changes (if they're ready): git add src/config.js && git commit -m "wip: config tweak", then switch branches
• Stash the changes (if not ready to commit): git stash, switch branches, and later git stash pop to bring them back on whichever branch you need them

Do not use git checkout -- src/config.js or git reset --hard to "make the error go away" unless you genuinely want to throw the local edits away permanently — those commands are destructive and unrecoverable for uncommitted changes.

How to describe this to a colleague: "I can't switch branches yet — I've got uncommitted changes to config.js. Let me stash them first." Using "stash" precisely (a temporary, named shelf for changes) rather than vaguely saying "save my changes somewhere" reads as fluent, not just correct.