Introduction

There is no safe magical version of git pull that simply ignores local changes and always does the right thing. You have to decide whether you want to keep those changes, temporarily set them aside, or discard them. Once that decision is explicit, the correct Git workflow becomes straightforward.

Safest Option: Stash, Pull, Then Reapply

If you want to keep your local work but get the latest upstream changes, stash first.

git stash push -u -m "temp before pull"
git pull --rebase
git stash pop

This is usually the right answer because it preserves local modifications instead of pretending they do not exist. The -u flag also includes untracked files, which are often the reason a pull still fails after a normal stash.

Using --rebase is not mandatory, but it keeps the history cleaner than a merge-based pull in many day-to-day workflows.

If You Truly Want To Discard Local Changes

Sometimes the local work does not matter and you want the branch to match the remote state. In that case, reset the tracked files and then pull.

git reset --hard HEAD
git pull

That removes uncommitted changes in tracked files. It does not remove untracked files or directories. If those also block the pull, clean them explicitly:

git clean -fd
git pull

This is destructive. Use it only when you are certain the local files are disposable.

If The Goal Is "Keep My File But Stop Git Touching It"

Some developers are really asking a different question: they have a local config file they do not want overwritten. git pull is not the real problem there. The issue is how that file is tracked.

One tool is:

git update-index --skip-worktree path/to/local-config.json

That tells Git to stop paying attention to local modifications for that tracked file in normal workflows. It is useful for machine-specific settings, but it is not a general replacement for proper environment-specific configuration.

To re-enable tracking:

git update-index --no-skip-worktree path/to/local-config.json

Know What git pull Actually Does

git pull is shorthand for two operations:

• 'git fetch'
• then merge or rebase

Git refuses to overwrite local changes because doing so silently would destroy work. So when people say "pull while ignoring local changes," they usually mean one of these:

• keep my work temporarily and update the branch,
• throw my work away,
• leave one local file alone permanently.

Those are different intents, so they need different commands.

A Good Workflow For Ongoing Work

If you are actively developing and frequently need upstream updates, this is a practical habit:

1git status
2git stash push -u -m "wip before sync"
3git pull --rebase
4git stash pop
5git status

This workflow forces you to inspect the repository before and after syncing. It reduces the chance of accidentally losing work or missing conflicts created when the stash is reapplied.

When A Separate Branch Is Better

If the local changes are meaningful but not ready to commit on the current branch, creating a temporary branch is often cleaner than repeated stashing.

1git switch -c wip/local-experiment
2git add .
3git commit -m "WIP checkpoint"
4git switch main
5git pull --rebase

This is especially useful when the "temporary" local changes have started to live for more than a few hours.

Common Pitfalls

• Looking for a single git pull flag that safely ignores all local changes in every case.
• Using git reset --hard before making sure the local work is truly disposable.
• Forgetting -u when stashing and then wondering why untracked files still block the pull.
• Using --skip-worktree for normal collaborative files instead of fixing configuration management.
• Pulling blindly without checking git status first.

Summary

• Decide first whether you want to keep, discard, or isolate the local changes.
• Use git stash push -u, then git pull --rebase, then git stash pop when you want to keep the work.
• Use git reset --hard and optionally git clean -fd only when you want to discard local changes.
• Use --skip-worktree only for narrow tracked-file cases, not as a general sync strategy.
• The right answer depends on intent, not on finding a special git pull shortcut.