Git Remote: Add Origin, Fetch, and Merge Remote Branches

Git is distributed, which means your repo and my repo can both be valid “sources of truth”. In practice, teams usually pick one remote as the shared source (often GitHub) and sync local work against it… but that’s just a convention. Let’s dig into how syncing Git repositories to GitHub works, and how that’s just one way to work with Git.

All the content from our Boot.dev courses are available for free here on the blog. This one is the “Remote” chapter of Learn Git. If you want to try the far more immersive version of the course, do check it out!

What Is a Git Remote?

A “remote” is just another Git repository connected to your local one.

There is no magical central repo built into Git itself. GitHub (the website) is not special to Git (the tool), it’s just a common place where teams host a shared repo. Other popular Git hosting services include GitLab and Bitbucket.

That shared repo is usually named origin… again just by convention.

How Do You Add origin to a Local Repository?

Use git remote add:

git remote add origin https://github.com/username/repo.git

Syntax:

git remote add <name> <uri>

For local practice repos, a relative path works great. For hosted remotes, that URI is almost always over HTTPS or SSH. For example, you can actually create a local “remote” by pointing to another local repo:

git remote add localorigin ../some-other-repo

Does Adding a Remote Download Everything?

Nope.

Adding a remote only stores the connection info. It does not download the remote’s object database into your local .git/objects yet.

That’s why a fresh repo can have a configured origin and still show no commits in local git log.

What Does git fetch Actually Do?

The git fetch command downloads commits, trees, blobs, and ref updates from the remote into your local Git database.

git fetch

The fetch command updates remote-tracking refs, but doesn’t merge anything into your current branch.

That’s why it’s safe to run often. You get new information without touching your working files.

If you’re trying to combine histories directly, that’s when Git Merge or Git Rebase comes in.

Why Does git log Show Nothing After Fetch Sometimes?

Because git log (without arguments) shows the history of your current local branch.

After fetch, you might have remote-tracking branches like origin/main, but your local main may still be empty or behind.

To inspect remote history directly:

git log --oneline origin/main

Or a feature branch:

git log --oneline origin/update_dune

How Do You Merge a Remote Branch Into Local main?

Once you’ve fetched:

git switch main
git merge origin/main

If your local main has no extra commits, this is often a fast-forward merge.

That means Git just moves your local branch pointer forward, no extra merge commit needed.

After that, plain git log on local main should match the history you saw in origin/main.

What’s a Good Basic Remote Workflow?

For day-to-day work, you can use fetch like this:

1. git fetch origin to get the latest commits and refs from the remote
2. update your local branch with rebase (or merge I guess) to incorporate those changes

But honestly, it’s much easier to just pull:

git pull origin main

This combines fetch and merge (or even better, rebase) into one step.

That pattern keeps your local state predictable and avoids… ahem… surprise conflicts. Basically what I’m saying is pull often!