Bringing other people’s work into yours
Pulling retrieves new changes from a remote repository and merges them into the branch you are currently on, so history created by colleagues or on another machine reaches your working copy.
Git’s documentation describes pull as a fetch followed by integration into the current branch. It is not simply downloading files.
How it differs from fetch
- Fetch: retrieve the remote’s new history so you can inspect it
- Pull: integrate what was retrieved into your current branch
When you do not want changes landing in your working branch immediately, fetch first and read the difference. That is why GitHub Desktop has separate Fetch origin and Pull origin buttons.
How it differs from clone
Cloning creates the working copy in the first place. Pulling updates a repository you already cloned.
Normally you clone once, then pull as needed.
Check your state first
Pulling with uncommitted changes can stop partway if they overlap. Check git status or your client, then commit or stash before pulling.
When the same lines changed on both sides, you get a merge conflict. Deciding what to keep requires a person to read both versions.
“Always pull before you start” is easy to remember, but running it on the wrong branch pulls in changes you did not want. Confirm the current branch, any uncommitted work, and the source before you run it.
The same applies when asking automation or an AI to pull. Rather than “get the latest”, specify which remote, which branch, and into which local branch.