Free lesson · Git Mastery

Remote Repositories Overview

Medium8 min readgit

Remote Repositories Overview

A note from Emeka Okafor, Senior Software Engineer at Netflix Data Platform.

Where the "Distributed" in Distributed Git Lives

Modules 1 through 8 covered Git operations on a single clone. Every command worked locally - committing, branching, merging, rebasing, all on the engineer's own machine. Nothing about that work was inherently collaborative. A team could use Git that way and never share code, and it would be Git running correctly.

The collaboration happens through remotes. A remote is a Git repository that lives somewhere else - on a colleague's machine, on a Git server, on GitHub or GitLab or a self-hosted system - and your local clone knows how to communicate with it. Push sends your commits to the remote. Fetch downloads the remote's commits to your local. Pull is fetch combined with merging.

When I joined the inaugural Andela cohort in Lagos in 2015, the program connected us to engineering mentors across continents. The code reviews came from senior engineers in San Francisco, Lagos, Nairobi, and London. The pull requests bounced across time zones. Every interaction relied on remotes - we were all on different machines, all working on the same codebases, and Git's remote infrastructure was what made it possible.

This topic covers what remotes are conceptually. The rest of Module 9 covers the specific operations: git remote for managing them (Topic 9.2), fetch (Topic 9.3), pull (Topic 9.4), push (Topic 9.5), upstream tracking (Topic 9.6), remote-tracking branches (Topic 9.7), and multiple-remote setups (Topic 9.8).

What a Remote Is

A remote is a named URL plus a few configuration entries pointing to another Git repository. From your local clone's perspective, a remote is "another place I can communicate with about this codebase."

git remote -v

This command lists the configured remotes. Each remote has a name on the left and a URL on the right. The dash v flag shows both the fetch URL and the push URL - they're usually the same, but can differ for advanced setups. Most repositories have a single remote called origin, which was set up automatically when the repository was cloned.

Sample output:

origin  git@github.com:netflix/data-platform.git (fetch)
origin  git@github.com:netflix/data-platform.git (push)

The name origin is just a convention - it's the default name Git uses when you clone a repository. The name has no special technical meaning; you could rename it to anything else and Git would treat it the same. The convention exists because almost every clone has at least one remote, and calling it "origin" makes documentation and tutorials consistent.

The Default Remote: origin

When you git clone <url> (Topic 2.2), Git automatically sets up a remote named origin pointing to the URL you cloned from. This is the standard case for most repositories - one clone, one remote, default name.

git clone git@github.com:netflix/data-platform.git
cd data-platform
git remote -v
# origin  git@github.com:netflix/data-platform.git (fetch)
# origin  git@github.com:netflix/data-platform.git (push)

After cloning, the origin remote is configured automatically. The URL matches what you cloned from. From this point forward, push and fetch without specifying a remote default to origin. The convention is silent - you don't think about it; the remote is just there.

For the rest of this module, when commands mention origin, they're referring to this default remote. Topic 9.8 covers cases where multiple remotes are configured.

The Protocols

Remotes can be accessed via several protocols. The URL prefix determines which:

git@github.com:netflix/data-platform.git    # SSH
https://github.com/netflix/data-platform.git # HTTPS
git://github.com/netflix/data-platform.git   # Git protocol (rare; less secure)
file:///path/to/another/clone                 # local filesystem

SSH and HTTPS are the common choices. SSH uses your SSH keys for authentication; HTTPS uses a token or credential helper. The Git protocol is older and rarely used today because it doesn't authenticate. The file colon slash slash slash form lets you treat a directory as a remote - useful for testing and for local synchronization.

The choice between SSH and HTTPS is mostly about authentication preference:

• SSH: authenticates via your SSH key pair. Setup involves generating a key, adding the public key to your account on the platform. Push and pull operations then work without prompting.
• HTTPS: authenticates via username and token (or credential helper). Push and pull prompt for credentials on first use; the credential helper caches them afterward.

Both work fine. I use SSH for personal repositories and SSH for work - the consistency makes the muscle memory simpler. Some organizations require HTTPS for compliance reasons.

What Operations Touch the Remote

Most Git commands operate locally - committing, branching, switching, merging, rebasing. They don't touch the remote at all. The commands that involve the remote are limited:

• git fetch - download commits and branches from the remote (Topic 9.3)
• git pull - fetch and then merge (Topic 9.4)
• git push - upload your commits to the remote (Topic 9.5)
• git clone - set up a new local repository from a remote (Topic 2.2)
• git remote - manage the remote configurations themselves (Topic 9.2)
• git ls-remote - query the remote's branches without downloading

That's essentially the list. The rest of Git's commands operate on local state.

The implication: working without internet access is fine for everything except the explicit remote operations. You can commit, branch, rebase, and merge entirely offline. When you reconnect, push and pull synchronize the work with the remote.

I take advantage of this constantly. Long flights between Los Gatos and London for team visits - I work the whole flight, committing on local branches. On landing, a single push synchronizes the work with the remote. The offline-first design is one of Git's underrated strengths.

A Pattern at Netflix

The Netflix Data Platform team is distributed across Los Gatos, Amsterdam, and other locations. Engineers commit locally to feature branches throughout the day, then push to GitHub when ready for review.

# Engineer's daily flow
git switch feature/event-pipeline
# ... work and commit locally ...
git push origin feature/event-pipeline

# Get colleagues' recent work
git fetch origin
git switch main
git merge origin/main

The pattern: commit work locally throughout the day, push when ready to share. Fetch to see what colleagues have pushed. The local operations are fast - no network round trips. The remote operations are explicit and infrequent. The combination makes distributed teams productive across time zones.

The discipline is implicit. Engineers don't think about which operations touch the remote and which don't; the muscle memory tells them. The result is that network availability doesn't block daily work, only synchronization.

Remote-Tracking Branches

A subtle but important concept: when you have a remote, your local clone keeps a snapshot of where each branch was on the remote the last time you fetched. These snapshots are called remote-tracking branches. Topic 9.7 covers them in depth.

The names follow a convention: <remote-name>/<branch-name>. For the default remote, your local view of the remote's main branch is called origin/main. Your view of the remote's feature/x branch is called origin/feature/x.

git branch -r

Dash r lists remote-tracking branches. These are different from your local branches - they're read-only snapshots of what the remote looked like at your most recent fetch. You don't commit to them directly; instead, you commit to your local branches and push, which updates the remote and then the corresponding remote-tracking branch.

Sample output:

  origin/HEAD -> origin/main
  origin/main
  origin/feature/event-pipeline
  origin/release/v2.4

The origin/HEAD -> origin/main line shows which branch the remote considers its default. The other entries are remote-tracking branches for each branch on the remote.

The crucial point: these are local references. They're updated when you fetch; they don't auto-update otherwise. Your origin/main might be hours or days out of date depending on how recently you fetched.

A Specific Story From Andela

In my first month at Andela, working from Lagos, the team was contributing to a shared repository hosted on GitHub. The mentors and other fellows were on different continents.

I'd commit work on my feature branch and push. A mentor in San Francisco would fetch, review, and leave comments. I'd address comments with new commits, push again. The mentor would fetch again, review the new commits, and approve. The platform handled the merge.

The thing that struck me about this workflow: I was contributing to a codebase used by people I'd never met, asynchronously, with no shared infrastructure beyond GitHub. The remote operations were the bridge - push from Lagos, fetch in San Francisco, no synchronization beyond the explicit operations.

The pattern was completely normal for the mentors. For me, coming from a context where collaboration meant being in the same room, it was a revelation. Remote-based collaboration scales across time, distance, and team size in ways that direct collaboration doesn't.

A Pattern at Booking.com

At Booking.com later in my career, the team contributed to a much larger codebase - hundreds of engineers, dozens of repositories, multiple remotes for some critical services. The patterns scaled because the underlying mechanics were the same.

The typical engineer's day:

• Pull at the start to get overnight changes
• Work locally, committing as the work progresses
• Push the feature branch when ready for review
• Fetch periodically to stay current
• Pull at the end to sync before the next day

Five operations a day on average, each taking seconds. The rest of the day is local work that doesn't touch the network. The pattern works for two engineers or two thousand engineers - the remote mechanics don't change.

What Comes Next

Topic 9.2 covers git remote for managing the remote configurations. Topic 9.3 covers fetch. Topic 9.4 covers pull. Topic 9.5 covers push. Topic 9.6 covers upstream tracking - the mechanism that connects local branches to remote-tracking branches. Topic 9.7 covers remote-tracking branches in depth. Topic 9.8 covers configurations with multiple remotes.

What Goes Wrong

Warning: Common remote-mental-model confusions:

Believing your local branches automatically sync with the remote. They don't. Push and pull are explicit operations.

Confusing the remote name with the URL. The name is a local alias; the URL is the actual location. You can rename remotes locally without affecting the URL.

Expecting origin to be special. It's just a name; you can rename or remove it like any other remote.

Treating remote-tracking branches as live views of the remote. They aren't. They reflect the state at your last fetch.

Forgetting that work without internet is fully supported. All local operations work offline.

Believing every operation touches the remote. Most don't. Only the explicit network commands do.

Try It

Exercise: Explore your remotes:

1. In a repository you've cloned, run git remote -v. Note the name and URL.
2. Run git branch -r to see remote-tracking branches. Note the naming convention.
3. Run git remote show origin to see detailed info about the default remote.
4. Try working offline: disable your network, make some commits, switch branches, merge. Note that everything works.
5. Reconnect, run git push to sync your work. Note that this is the moment the network is involved.
6. Read your team's documentation on the remote URL conventions and authentication setup. Verify your configuration matches.

Back to Git Mastery