How Git remotes work
Git is a distributed version control system. Every developer has a full copy of the repository on their machine, including the entire commit history. A remote is simply a reference to another copy of that repository, usually hosted on a server like GitHub, GitLab, or Bitbucket.
When you clone a repository, Git automatically creates a remote called origin that points to the URL you cloned from. This is your default connection to the server. You can add more remotes if you need to sync with multiple sources — for example, an upstream remote to track the original project when contributing to a fork.
Local vs Remote: Your local repository lives on your machine. Remote repositories live on servers. Git commands like fetch, pull, and push are the bridges that sync changes between the two. Without these commands, your local work stays invisible to everyone else.
Clone a repository
Cloning is the first step when joining an existing project. It creates a local copy of the entire repository, including all branches and commit history.
git clone
git clone URL downloads a remote repository to your machine and sets up the origin remote automatically. You get a fully functional repository ready for work. You can clone via HTTPS or SSH depending on your authentication setup.
Read the full guide: git clone explained
Manage remotes
Once you have a repository, you may need to inspect, add, or remove remote connections. The git remote command handles all of this.
git remote
git remote -v lists all configured remotes with their URLs. Use git remote show origin to get detailed information about a specific remote, including which branches are tracked and whether your local branches are up to date.
Read the full guide: git remote explained
Add and remove remotes
You can connect your repository to multiple remotes. This is essential for open-source workflows: origin points to your fork while upstream points to the original repository. Use git remote add and git remote remove to manage these connections.
Sync with remotes
Three commands form the core of remote synchronization: fetch downloads changes, pull downloads and merges, and push uploads your commits. Understanding the difference between these three is key to smooth collaboration.
git fetch
git fetch downloads new commits, branches, and tags from a remote without modifying your working directory. It updates your remote-tracking branches (like origin/main) so you can review changes before integrating them. It's the safe way to check what's new.
Read the full guide: git fetch explained
git pull
git pull is essentially git fetch followed by git merge. It downloads remote changes and immediately integrates them into your current branch. It's convenient but can introduce merge conflicts if your local branch has diverged from the remote.
Read the full guide: git pull explained
git push
git push uploads your local commits to a remote repository. This is how you share your work with the team. The first time you push a new branch, use the -u flag to set up tracking: git push -u origin branch-name.
Read the full guide: git push explained
Fetch vs Pull: which to use?
This is one of the most common points of confusion for Git beginners. Both commands download changes from a remote, but they behave very differently. Here's a side-by-side comparison.
| git fetch | git pull | |
|---|---|---|
| Downloads changes | Yes | Yes |
| Modifies working directory | No | Yes |
| Merges into current branch | No | Yes (fetch + merge) |
| Risk of conflicts | None | Possible |
| Review before integrating | Yes — inspect with git log or git diff | No — changes are merged immediately |
| Best for | Checking what changed on the remote | Quickly updating your local branch |
Rule of thumb: use git fetch when you want to see what's new without touching your work. Use git pull when you're ready to integrate remote changes into your branch. Many experienced developers prefer to fetch first, review with git log origin/main, and only then merge manually for maximum control.
For a more detailed breakdown, see our dedicated comparison: git pull vs fetch
Collaboration workflow
In a typical team workflow, every feature or fix follows the same cycle. Understanding this pattern is essential for working effectively with others. Here is the standard flow most teams follow:
- Clone the repository (once, when joining the project).
- Create a branch for your feature or bug fix.
- Make commits with clear, descriptive messages.
- Push your branch to the remote.
- Open a Pull Request (or Merge Request) for code review.
- Merge the branch into
mainafter approval. - Pull the latest
mainbefore starting the next feature.
This feature-branch workflow keeps the main branch stable while allowing everyone to work in parallel. Each branch is isolated, so one developer's work never interferes with another's until the code is reviewed and merged.
Common remote errors
Working with remotes can produce confusing error messages. Here are the most frequent ones and how to resolve them:
error: failed to push some refs
This happens when the remote branch has commits your local branch doesn't have. Someone pushed changes before you. Fix it by running git pull first, then push again. See the full troubleshooting guide.
fatal: remote origin already exists
You tried to add a remote named origin but one already exists. Use git remote set-url origin NEW_URL to update the URL instead, or remove the existing remote first with git remote remove origin. See the full troubleshooting guide.
Browse all Git error solutions in our Git error reference.