git pull --force is a valid command, but it is not an “overwrite my local files” switch. The force option affects Git’s fetch step: it can allow a fetched reference to move in a way Git would otherwise reject. The subsequent integration still follows normal pull behavior. If your goal is to replace local work with a remote branch, inspect and preserve what matters before considering a reset.
What does git pull --force actually do?
A pull has two parts: fetch changes from another repository, then integrate a branch into your current branch. Depending on your command and configuration, integration may fast-forward, rebase, or merge. The Git pull documentation describes --force among its fetch options. It does not turn the integration step into a hard reset of your branch or working tree.
That distinction matters if a pull reports a conflict or refuses to continue because of local changes. Adding --force is not a reliable way to resolve either condition, and it can obscure what state you intended to keep.
First decide which of these outcomes you want:
- Keep local edits and commits: save the edits, fetch, and integrate the remote branch.
- Discard local commits and tracked edits: after inspection, reset your current branch to a specific remote-tracking commit.
- Remove untracked files too: preview them separately before using
git clean.
The commands are different because the data at risk is different.
Inspect your branch before changing it
Run these commands from the repository you intend to update:
git status --short --branch
git branch --show-current
git branch -vv
git diff
git diff --cached
git fetch origin
git log --oneline origin/main..HEAD
Replace main with the branch you actually intend to follow. git branch -vv shows the current branch's configured upstream, if it has one. git status shows tracked edits and visible untracked files. The two diff commands show unstaged and staged changes. After git fetch origin, the final command lists commits reachable from your current branch but not from origin/main—commits a reset to origin/main would leave behind.
Fetching updates your local view of remote references without integrating those commits into your checked-out branch or rewriting your working files. Check the fetched target before proceeding:
git log -1 --oneline origin/main
git diff --stat HEAD origin/main
A dirty working tree, an unexpected branch name, or local commits you still need are reasons to stop and preserve work. Avoid running a copied reset command with origin/main when your branch actually tracks another remote or branch.
Keep your changes and update the branch
If you have uncommitted edits, a stash can put them aside while you update. Include untracked files when they matter:
git stash push --include-untracked -m "before updating branch"
git stash list -1
git fetch origin
Git stash saves tracked changes and, with --include-untracked, untracked files. It does not include ignored files; check for local configuration, generated data, or other files outside Git before relying on it as a complete backup. A stash may also contain secrets, so treat it as repository data.
Confirm that stash push created a new entry and note its identity. If it reports No local changes to save, skip the later stash apply; otherwise, a plain apply could restore an older, unrelated stash.
If your local branch has no commits ahead of its upstream and you only want a fast-forward, use:
git pull --ff-only
git stash apply stash@{0}
git status
git pull uses the configured upstream. Confirm it is the branch you intend to follow before running this sequence; if it is not, specify the intended remote and branch explicitly. --ff-only stops rather than creating a merge commit or replaying divergent history. Apply stash@{0} only if it is still the new entry you just created; otherwise use that entry's recorded identity. Applying a stash can produce conflicts, and plain stash apply does not necessarily restore which changes were staged. Inspect the result and keep the stash until you have verified your files. Do not automatically drop it.
If you have local commits worth keeping, fetch and choose an integration method instead of resetting. On a private feature branch, git rebase origin/main can replay those commits on the fetched main branch. On a shared branch, coordinate before rewriting its history. If a merge is more appropriate for your team, use that instead. Neither option requires git pull --force as an overwrite shortcut.
A backup branch does not save uncommitted files
Before a deliberate reset, you can preserve your current committed branch tip:
git branch backup/main-before-reset
That branch points to the current commit. It does not contain unstaged edits, staged changes that were never committed, or untracked files. Stash or otherwise save those separately. This distinction is easy to miss when an article says only “make a backup branch.”
If you are uncertain whether local work is disposable, preserve it first. A branch and stash are easier to inspect than trying to reconstruct lost edits afterward.
Match a remote branch only when local work is disposable
A hard reset is a different operation from pull. After checking the current branch, reviewing local commits, and preserving anything important, the explicit sequence is:
git fetch origin
git log -1 --oneline origin/main
git reset --hard origin/main
git status --short --branch
The reset is destructive. It moves your current branch to origin/main, resets the index, and overwrites tracked working-tree files to match that commit. It can also remove untracked files that obstruct files being written by the reset. It does not generally clear every untracked or ignored file. The Git reset documentation describes these effects.
Do not run this sequence merely because a pull produced a conflict. It is appropriate only when you intentionally want to discard your local branch state and have confirmed the exact remote-tracking target.
If remaining untracked files also need to go, preview them first:
git clean -nd
Review every listed path. Only if you intend to delete those untracked files and directories should you run:
git clean -fd
git clean -fd removes untracked data; a hard reset will not restore it. Ignored files are normally excluded from this clean operation. Avoid adding -x casually: that option also targets ignored files, which may include local configuration or build data. See the Git clean documentation for its dry-run and scope rules.
What can reflog recover?
If a reset moved your branch away from a commit, inspect the local reference history:
git reflog -n 10
Find the commit you meant to keep, inspect it, and create a recovery branch pointing to it:
git show --stat <commit-id>
git branch recovered-work <commit-id>
This preserves the identified commit without immediately resetting your current working tree again. Git reflog records recent updates to branch tips and other references; entries can expire. It is useful for finding commits that a reset made hard to reach.
Reflog is not a backup of uncommitted edits. If tracked changes were never committed or stashed before reset --hard, reflog cannot recreate them. Likewise, it does not restore untracked files deleted by git clean. That is why inspection and preservation belong before the destructive commands, not after them.
Choose the command by the work you want to keep
Use ordinary git pull --ff-only when a clean branch can fast-forward. Use stash plus fetch when local files need to be set aside. Use rebase or merge when local commits matter. Use fetch plus reset --hard only when replacing the current branch is intentional, and treat git clean as a separate deletion decision.
git pull --force does not make those choices for you. The safe command is the one that matches the local state you inspected and the work you decided to preserve.