Git Rescue

Only if the file was staged with git add at some point. Staging writes the content into Git's object database, where it survives as a dangling blob that git fsck --lost-found can recover. If the file was never staged and never committed, Git never saw it and cannot help — your editor's local history or your operating system's file-versioning feature is the realistic route.

git reflog. It lists every position HEAD and your branches have held, including states no branch points to any more, and it keeps them for 90 days by default. Commits lost to a bad reset, a botched rebase or a deleted branch are almost always sitting in the reflog waiting to be pointed at again.

Committed work is effectively safe until garbage collection prunes unreachable objects, typically weeks later. The genuinely unrecoverable category is content Git never received: uncommitted, unstaged edits destroyed by git reset --hard, git restore or git clean. If Git was never given the bytes, no Git command can produce them.

git reset moves your branch pointer and can rewrite the index and working directory — it changes history. git revert adds a new commit that undoes an earlier one, leaving history intact, which makes it the safe choice on shared branches. git restore only affects file contents in your working directory or index and never touches history at all.

All three move your branch pointer back. --soft leaves the index and working directory untouched, so the undone changes stay staged. --mixed (the default) also resets the index, so the changes remain as unstaged edits. --hard resets the working directory too, permanently discarding uncommitted changes — the only one of the three that can lose work.

Merge when the branch is shared or when you want history to reflect what genuinely happened. Rebase when the branch is yours alone and you want a clean linear history before opening a pull request. The rule that matters: never rebase commits that have already been pushed somewhere others pull from.

Reflog entries for reachable commits last 90 days and unreachable ones 30 days, after which git gc can prune the objects. Those defaults are configurable via gc.reflogExpire and gc.reflogExpireUnreachable. In practice you have weeks — but run git fsck sooner rather than later, and avoid git gc --prune=now while you're recovering.

It walks every object in .git/objects and reports the ones nothing references, writing them into .git/lost-found so you can browse them as real files. Dangling blobs are file contents from staged-but-never-committed work; dangling commits are whole snapshots from deleted branches and dropped stashes. It's the deepest recovery layer Git has.

On a branch only you use it's routine and fine. On a shared branch it can destroy work others have pushed. Always prefer git push --force-with-lease, which aborts if the remote has moved since you last fetched — it prevents exactly the accident that plain --force causes.

Almost always because the remote has commits you don't have locally, so completing the push would orphan them. Run git pull --rebase to bring their work in and replay yours on top, then push again. The rejection is Git's most valuable safety check — force-pushing past it deletes whatever caused it.

GitHub removed password authentication for Git operations in August 2021. Use a personal access token in place of the password, or switch the remote to SSH and authenticate with a key. If you already created a token and it still fails, your credential helper is replaying the old one — clear the stored credential for github.com.

No. Git is a complete version control system that works entirely offline, with full history, branching and commits on your own machine. GitHub, GitLab and Bitbucket are hosting platforms that add pull requests, issues, CI and a shared remote — convenient for collaboration, but not required.

git fetch downloads new commits and updates your remote-tracking branches without touching your files — completely safe, and it lets you inspect what's coming before accepting it. git pull is a fetch followed immediately by a merge or rebase into your current branch, which is why it's the command most likely to drop you into an unexpected conflict.

It means HEAD points directly at a commit instead of at a branch, which happens when you check out a hash or tag. It's a normal state — bisect and CI use it deliberately — and only becomes a problem if you commit and then switch away, because those commits have no branch referencing them. Running git switch -c <name> before leaving avoids it entirely.

git reset --soft HEAD~1 removes the commit and leaves every change staged, ready to be recommitted. Use the default --mixed mode if you'd rather have the changes unstaged. Avoid --hard unless you genuinely want the work destroyed, and if the commit is already pushed use git revert instead.

Because .gitignore only applies to untracked files. Once a file has been committed, Git keeps tracking it regardless of ignore rules. Run git rm --cached <file> to untrack it while keeping your local copy, then commit — the ignore rule takes effect from that point.

Usually line endings or file permissions. Windows writes CRLF and Unix writes LF, so the same file differs byte for byte across platforms — fix it with a committed .gitattributes containing `* text=auto` plus a one-off git add --renormalize. If the diff shows only mode lines, set core.fileMode false instead.

Git works if you set up Git LFS before committing binaries, so textures, audio and models are stored as pointers rather than full copies in every commit. Without LFS the repository bloats quickly and never shrinks. For studios versioning hundreds of gigabytes, Perforce or Unity Version Control genuinely handle it better.

Yes, but only with setup. Set Asset Serialization to Force Text in Unity's editor settings, then register UnityYAMLMerge as Git's merge tool for .unity and .prefab files via .gitattributes. Without both, Git's line-based merge can silently corrupt a scene's internal object references.

Rotate the credential first — that's the only step that actually restores security, since bots scrape public repositories within seconds and old commits may already be cached or cloned. Then purge it from history with git filter-repo and force-push. Deleting the file in a new commit does nothing, because every earlier commit still contains it.

Find the biggest objects by piping git rev-list --objects --all through git cat-file --batch-check, then remove them from history with git filter-repo --strip-blobs-bigger-than. Follow up with git reflog expire and git gc --prune=now to actually reclaim the disk, and move future binaries into Git LFS.

The two branches share no common ancestor, so Git has no base to merge against. It usually means you initialised a repository locally and separately on the host. Add --allow-unrelated-histories to proceed — but first check you aren't accidentally merging two genuinely different projects, which is what the guard is for.

Yes, as long as no Git process is genuinely running. The lock exists only to stop two commands writing the index simultaneously; if the process that created it died, the file is stale and Git recreates it when needed. Close any IDE or Git GUI first — they run Git in the background constantly.

About a dozen cover ninety percent of daily work: status, add, commit, push, pull, switch, branch, merge, log, diff, restore and reset. The rest are worth knowing about so you recognise them when a situation calls for one — reflog and fsck in particular, because they're what get your work back.

Yes — completely free, with no account, no sign-up and no limits. Every command reference and rescue guide is a static page you can read, search and copy from, and nothing you type is sent anywhere.