Lesson 2 - Connecting Local to Remote

Welcome to Connecting Local to Remote#

In Lesson 1 you created an empty repository on GitHub and learned how local and remote copies relate. Right now those two halves don’t know about each other: your SkyLog project sits on your laptop with all its commits, and the GitHub repo sits online, empty and waiting. This lesson joins them. You’ll register the remote with your local repo, publish your commits with your first git push, and set up a tracking link so every push after that is a single short command.

We’ll keep using the SkyLog project and its GitHub repo. The remote’s URL is [email protected]:datatweets/skylog.git (the SSH form; the HTTPS form would be https://github.com/datatweets/skylog.git).

By the end of this lesson, you will be able to:

• Register a remote with git remote add origin <url> and inspect it with git remote -v
• Explain why origin is the conventional name for your main remote
• Publish your work with git push -u origin main and explain what -u does
• Recognize the origin/main remote-tracking branch in git branch -a
• Push later changes with just git push

Let’s begin.

Registering the Remote with git remote add#

A remote is really just a name paired with a URL that your local repository remembers. Adding one doesn’t move any files — it simply records where the hosted copy lives so Git knows where to send commits. You create that pairing with git remote add, giving the remote a name and the URL you got from GitHub:

$ git remote add origin [email protected]:datatweets/skylog.git

That command produces no output, which is normal — it just stores the mapping. To confirm it worked, list your remotes with git remote -v (the -v is for verbose, so you see the URLs too):

$ git remote -v
origin  [email protected]:datatweets/skylog.git (fetch)
origin  [email protected]:datatweets/skylog.git (push)

Two lines appear for the one remote: Git tracks the URL it would fetch from (pull commits down) and the URL it would push to (send commits up) separately. For nearly every project these are identical, as they are here.

Notice the name we chose: origin. There’s nothing magic about that word — Git would happily accept github or backup or anything else. But origin is the long-standing convention for the primary remote a repo was published to or cloned from. Sticking to it means that when you later read someone else’s instructions like git push origin main, they work without translation. Use origin unless you have a specific reason not to.

The First Push with git push -u origin main#

With the remote registered, you can publish your commits. The push command names the remote and the branch you’re sending:

$ git push -u origin main
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

Over a real network connection, Git prints object-transfer progress before those lines — messages such as Enumerating objects: 6, done., Counting objects: 100% ..., and Writing objects: 100% ... as it packs up and uploads your commits. Don’t be surprised by that scroll of activity; the exact numbers depend on your project. The two lines that matter are the ones shown above:

• * [new branch] main -> main confirms your local main was published as a new branch named main on the remote.
• branch 'main' set up to track 'origin/main'. is the result of the -u flag.

The -u (short for --set-upstream) does one extra thing beyond pushing: it records a permanent link between your local main and the remote’s main. That link is called the upstream, and it’s what makes future commands so short — Git now knows, without being told, which remote and branch your main is associated with. You only need -u on the first push of a branch.

The origin/main Remote-Tracking Branch and Later Pushes#

After that first push, something new exists locally. List every branch, including remote ones, with git branch -a (the -a means all):

$ git branch -a
* main
  remotes/origin/main

The first line, * main, is your local branch (the * marks the one you’re on). The second, remotes/origin/main, is a remote-tracking branch: a local bookmark that records where origin’s main was the last time you communicated with it. You don’t edit it directly — Git updates it for you whenever you push or fetch. It’s how your repo remembers the state of the remote between network operations, and it’s the half that your upstream link points at.

Because the upstream is now set, you never need to spell out the remote and branch again. From here on, a plain command does the job:

$ git push

Git reads the upstream you established with -u, sees that main tracks origin/main, and sends your new commits there automatically. The same shorthand works in the other direction with git pull, which you’ll explore in the next lesson.

Practice Exercises#

Exercise 1: Add and verify a remote#

You’ve created an empty GitHub repo at https://github.com/datatweets/skylog.git and want to register it locally as origin. Write the command to add it, and the command to confirm it was added.

Exercise 2: Why -u on the first push?#

You ran git push -u origin main and saw branch 'main' set up to track 'origin/main'. What did the -u accomplish, and will you need it again next time you push from this branch?

Exercise 3: Reading git branch -a#

After your first push, git branch -a shows * main and remotes/origin/main. What is remotes/origin/main, and did you create it by hand?

Summary#

Connecting a local repository to a remote is a two-step act: register, then publish. You register with git remote add origin <url>, which stores a name-and-URL pairing (no files move yet), and you inspect it with git remote -v, which shows the fetch and push URLs for origin — the conventional name for your primary remote. You publish with git push -u origin main; the -u flag sets the upstream, linking your local main to origin/main so that later you can push with a bare git push. After that first push, git branch -a reveals a new remotes/origin/main remote-tracking branch, which Git maintains automatically to remember the remote’s state.

Key Concepts#

• git remote add origin <url> — registers a remote by name and URL; no files are transferred.
• git remote -v — lists remotes with their fetch and push URLs.
• origin — the conventional name for a repository’s primary remote.
• git push -u origin main — publishes main and sets its upstream to origin/main.
• Upstream tracking — the link that lets bare git push / git pull know where to go.
• origin/main — a remote-tracking branch recording the remote’s last-known state, shown by git branch -a.

Why This Matters#

This is the moment a project stops being purely local. Once your commits are on the remote, they’re backed up, shareable, and ready for collaborators. The upstream link you set with -u is a small detail that pays off constantly: every push and pull for the rest of the project shrinks to a single word because Git already knows where your branch belongs. Understanding the origin/main remote-tracking branch also prepares you for the next lesson, where keeping local and remote in sync — fetching, pulling, and pushing — becomes routine.

Next Steps#

Continue Building Your Skills#

Your local SkyLog repo and its GitHub remote are now connected, and your first commits are online. Next you’ll work in both directions — pulling down changes that exist on the remote and pushing up your own — so that local and remote stay in step no matter where the latest work was done.