Panic Situations

Panic You are in 'detached HEAD' state

HEAD detached at a3f2c1b You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch.

This happens when you checkout a commit hash, tag, or remote branch directly instead of a local branch. Any commits you make here are "floating" and can be lost.

1Check where HEAD is pointing:

git log --oneline -5

2If you have no new commits to save, just switch back to your branch:

git checkout main

3If you made commits you want to keep, create a new branch from here first:

git checkout -b my-recovery-branch

4Then merge or rebase that branch into main as needed.

Tip: Always checkout branch names (e.g. git checkout main) rather than commit hashes to avoid detached HEAD.

Panic I need to undo my last commit

Committed too early, wrong branch, or included the wrong files?

There are two safe ways to undo a commit depending on whether you want to keep your changes.

1Soft reset — undo the commit but keep changes staged (safest):

git reset --soft HEAD~1

2Mixed reset — undo the commit and unstage changes (files still modified):

git reset HEAD~1

3Hard reset — undo the commit AND discard all changes permanently:

git reset --hard HEAD~1

Danger: --hard permanently deletes your uncommitted changes. There is no undo. Use --soft unless you are certain.

Already pushed? Use git revert HEAD instead — it creates a new commit that undoes the last one without rewriting history.

Panic I did git reset --hard and lost my work

git reset --hard HEAD~3 # oops, lost commits

Don't panic! Git doesn't immediately delete lost commits. You can recover using the reflog.

1View the reflog (your HEAD history):

git reflog

2Find the commit hash before the reset (e.g., abc1234). Then recover:

git checkout -b recovery-branch abc1234

Tip: The reflog keeps a record of all HEAD movements for about 90 days. Act quickly.

Merge & Rebase

Merge CONFLICT (content): Merge conflict in <file>

Auto-merging src/app.js CONFLICT (content): Merge conflict in src/app.js Automatic merge failed; fix conflicts and then commit the result.

Git couldn't automatically merge two branches because the same lines were changed differently in each.

1See which files have conflicts:

git status

2Open each conflicted file. Look for conflict markers and edit to keep the correct code:

<<<<<<< HEAD your changes here ======= incoming changes here >>>>>>> feature-branch

3After editing, mark each file as resolved:

git add src/app.js

4Complete the merge:

git commit

Tip: Use git mergetool to open a visual diff tool, or use VS Code's built-in merge editor.

Merge Rebase went wrong — how do I abort?

error: could not apply a3f2c1b... my commit message hint: Resolve all conflicts manually, mark them as fixed with hint: "git add/rm <conflicted_files>", then run "git rebase --continue".

A rebase in progress with conflicts can be safely aborted to restore your branch to its pre-rebase state.

1Abort the rebase entirely and go back to where you started:

git rebase --abort

2Or, if you want to fix conflicts and continue:

git add .

git rebase --continue

3To skip a problematic commit entirely:

git rebase --skip

Tip: git rebase --abort is always safe — it fully restores your branch to its original state before the rebase started.

Merge When to use reset vs revert?

Both undo changes, but they work very differently and are suited to different situations.

1Use git revert when the commit has already been pushed to a shared branch. It creates a new commit that undoes the changes — safe for team repos:

git revert HEAD

git revert <commit-hash>

2Use git reset only on local, unpushed commits. It rewrites history:

git reset --soft HEAD~1

Never use git reset on commits that others have already pulled. It rewrites history and will cause conflicts for your teammates.

Rule of thumb: Pushed = revert. Local only = reset.

Remote & Push

Remote error: failed to push some refs — push rejected

! [rejected] main -> main (fetch first) error: failed to push some refs to 'https://github.com/user/repo.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. Integrate the remote changes before pushing again.

Someone else pushed to the remote branch since your last pull. You need to integrate their changes first.

1Pull the latest changes and merge:

git pull origin main

2Or pull with rebase for a cleaner history:

git pull --rebase origin main

3Resolve any conflicts, then push:

git push origin main

Do not use git push --force on shared branches. It overwrites others' work. Only use force-push on your own feature branches.

Remote SSL certificate problem: unable to get local issuer certificate

fatal: unable to access 'https://github.com/user/repo.git/': SSL certificate problem: unable to get local issuer certificate

Git can't verify the SSL certificate of the remote server. Common on corporate networks with custom CA certificates or misconfigured Git installs.

1Update your CA certificate bundle (preferred fix on Linux/Mac):

git config --global http.sslCAInfo /path/to/ca-bundle.crt

2On Windows, update Git for Windows to the latest version — it bundles an updated CA store.

3If on a corporate network, ask IT for the internal CA certificate and add it to Git's trust store.

4Temporary workaround only (not for production):

git config --global http.sslVerify false

Disabling SSL verification is a security risk. Only use it as a temporary diagnostic step, never permanently.

Remote fatal: refusing to merge unrelated histories

fatal: refusing to merge unrelated histories

This happens when you try to merge two branches that have no common commit ancestry (e.g., a new repo with an existing one).

1If you are sure you want to merge (e.g., initializing a project with an existing history), use the --allow-unrelated-histories flag:

git pull origin main --allow-unrelated-histories

2Or when merging a branch:

git merge other-branch --allow-unrelated-histories

Tip: Use this only when you understand the consequences — you will merge two completely different commit histories.

Working Tree

Common warning: LF will be replaced by CRLF / CRLF line endings

warning: LF will be replaced by CRLF in file.txt. The file will have its original line endings in your working directory.

Windows uses CRLF line endings, Unix/Mac use LF. Git is warning you about automatic conversion. This can cause noisy diffs and cross-platform issues.

1On Windows — auto-convert on checkout, commit as LF (recommended for cross-platform teams):

git config --global core.autocrlf true

2On Linux/Mac — commit as-is, no conversion:

git config --global core.autocrlf input

3For team consistency, add a .gitattributes file to your repo root:

* text=auto eol=lf

Tip: A .gitattributes file overrides individual developer settings and is the most reliable way to enforce consistent line endings across a team.

Common Untracked files cluttering my working tree

Untracked files: (use "git add <file>..." to include in what will be committed) node_modules/ .env dist/

Files Git doesn't know about yet. You either want to track them, ignore them, or remove them.

1Add files you want to track:

git add <filename>

2Ignore files permanently by adding them to .gitignore:

echo "node_modules/" >> .gitignore

3Preview what would be deleted before cleaning:

git clean -n

4Remove all untracked files (irreversible):

git clean -fd

git clean -fd permanently deletes files. Always run git clean -n first to preview what will be removed.

Common Stash conflict — cannot apply stash

error: Your local changes to the following files would be overwritten by merge: src/app.js Please commit your changes or stash them before you merge. Aborting

Your stashed changes conflict with the current state of the working tree. Git can't apply the stash cleanly.

1List your stashes to find the right one:

git stash list

2Try applying with conflict markers instead of popping:

git stash apply stash@{0}

3Resolve the conflict markers in the affected files, then stage them:

git add src/app.js

4Once resolved, drop the stash entry:

git stash drop stash@{0}

Tip: Use git stash apply instead of git stash pop when you're unsure — it keeps the stash entry until you manually drop it, so you can retry if something goes wrong.

Common Submodule errors — not checked out or dirty

fatal: Not a git repository: ../.git/modules/path/to/submodule

Submodules often get out of sync after switching branches or pulling changes.

1Initialize and update all submodules recursively:

git submodule update --init --recursive

2To update all submodules to their latest remote commit:

git submodule update --remote --merge

3If submodule has uncommitted changes you want to discard:

git submodule foreach --recursive git reset --hard

Tip: After a git pull, always run git submodule update --init --recursive to sync submodules.

Detailed Guide: Mastering Git Troubleshooting in 2026

As we move through 2026, Git remains the indispensable foundation of collaborative software development. However, its power comes with a steep learning curve, and even experienced developers occasionally find themselves in "panic situations"—whether it's a detached HEAD, a messy merge conflict, or a pushed commit that needs to be undone. Understanding how to navigate these errors is not just about fixing bugs; it's about maintaining a clean, professional commit history and ensuring the integrity of your codebase. Our Fix Git Errors guide provides clear, step-by-step solutions for the most common Git hurdles, helping you resolve issues with total confidence.

A key focus for modern development is the distinction between "Reset" and "Revert." In 2026, with the prevalence of CI/CD and automated deployments, rewriting history on shared branches can be disastrous. Our guide emphasizes the "Pushed = Revert, Local = Reset" rule, ensuring you use the right tool for the job without disrupting your teammates' workflows. By prioritizing safety and transparency, we help you manage your version control in a way that is both powerful and predictable, reducing the stress of technical debt and collaboration friction.

Finally, consider the role of "Local-First" diagnostics. In an era where privacy and security are paramount, AllOmnitools provides a secure environment for auditing your Git history and exploring recovery commands. You never need to share your repository details or proprietary commit hashes with a third-party server. Everything happens entirely within your browser, providing a high-performance, private utility that respects your data. By combining these troubleshooting steps with other AllOmnitools like the Git Cheat Sheet, you have a complete ecosystem for mastering version control in 2026.

Why Choose AllOmnitools?

Frequently Asked Questions

What's the difference between git reset and git revert?

git reset moves the branch pointer backward, effectively deleting commits from the history. git revert creates a new commit that undoes the changes of a previous one. Rule: pushed = revert. Local-only = reset.

How do I recover a lost commit after git reset --hard?

Don't panic! Use git reflog to see your HEAD history. Find the commit hash before the reset, then use git checkout -b recovery-branch [hash] to restore it.

When should I use git rebase --abort?

Use it whenever a rebase becomes too complex or you encounter too many conflicts. It safely restores your branch to its exact state before the rebase started.

Is my data safe when using this guide?

Yes. AllOmnitools is "local-first." We provide the information and code snippets locally in your browser. You never need to submit your proprietary Git details to our servers.

Why am I getting "push rejected" errors?

This usually means someone else has pushed to the remote branch since your last pull. You need to pull their changes, resolve any conflicts, and then try your push again.

Can I undo a git add . before committing?

Yes. Use git reset (with no arguments) or git restore --staged . to unstage all files while keeping your local modifications intact.

What are Git submodules and why do they cause errors?

Submodules are references to other repositories. Errors often occur when they are not initialized or updated. Always run git submodule update --init --recursive after cloning or pulling.

Fix Git Errors

People Also Use These Tools