What is the difference between git pull and git fetch?

git fetch and git pull both get changes from a remote repository, but they work differently. Understanding the difference helps avoid unexpected conflicts.

git fetch downloads changes from remote but doesn't apply them to your working directory. Only remote-tracking branches are updated (origin/main, origin/feature, etc.). Your local branch and working files remain untouched. After fetch, you can review changes: git log origin/main, git diff main origin/main. This is safe — you break nothing, just get information about new commits.

git pull = git fetch + git merge. First downloads changes, then immediately merges them with your current branch. If there are new commits in remote and you have local changes, pull will create a merge commit or, on divergence, conflicts. This can be unexpected if you didn't check what exactly changed in remote.

When to use fetch: always, when you want to see what's new in remote before applying. Especially useful before starting work — run git fetch in the morning, check git log origin/main, and if everything is fine, do git merge or git rebase. Also fetch is needed to view others' feature branches without switching to them.

When to use pull: when you're confident there are no unexpected changes in remote and want to update quickly. For example, you're the only developer on a branch or changes are trivial.

Pull with rebase: git pull --rebase instead of merge applies your local commits on top of downloaded ones. This gives linear history without merge commits. You can set it as default: git config --global pull.rebase true. Many teams prefer this option.

Practical tip: use git fetch by habit, and git pull — only when you know exactly what you'll get. This saves you from unexpected conflicts at the wrong moment.