Why remotes change everything — Git remotes: push & pull

Everything so far has been one machine

Every commit, branch, and undo trick from the last two courses happened entirely on your laptop. That is a complete, working version control system, and also, on its own, a single point of failure. Spill coffee on that laptop and every commit you ever made disappears with it. Worse: nobody else can see a single line of your work.

A remote is another copy of your repository, reachable over a network: most often hosted on GitHub, GitLab, or Bitbucket. Git itself doesn't require any of these; they are companies that host Git repositories and add collaboration tools (issues, pull requests, CI) on top of plain Git.

The two directions

              git push
Local repo  ───────────▶  Remote repo (GitHub)
(your laptop)  ◀───────────  (server)
              git pull

push sends your local commits somewhere else; pull brings someone else's commits (or your own, from another machine) back down. That's the entire mental model this course builds on: everything from here is detail on top of these two arrows.

What a remote buys you

Backup: a remote is a full copy of your history, independent of your laptop.
Collaboration: teammates push and pull from the same remote, seeing each other's committed work.
A deploy trigger: pushing to a specific branch is how many CI/CD pipelines and hosting platforms know to build and deploy your app.
Portfolio and code review: GitHub is where pull requests, issue tracking, and your public commit history live: the artifact a hiring manager looks at.

GitHub is not Git

This distinction matters and confuses beginners constantly: Git is the version control tool running on your machine, doing everything the last two courses covered. GitHub is a website that hosts Git repositories and layers a UI, permissions, and workflow tools on top. You could push to a remote that isn't GitHub at all: a GitLab server, a company's private server, even another folder on your own machine. This course uses GitHub because it's the overwhelming industry default, but every command works identically against any Git remote.

How this course is organized

Authenticate with GitHub using SSH keys: once, and you never type a password for Git again
Connect an existing local repo to a new remote with git remote add
git push: send commits, and set up the tracking relationship
git clone: start from a remote instead of git init
git fetch vs. git pull: look before you leap
Push a real Rails project to GitHub end to end

What this course does not cover yet

Two people editing the same file and combining their changes (merging and resolving conflicts) is a real situation. It has its own course, Git merging & conflicts, right after the branching course. Everything here assumes changes arrive cleanly; the moment they don't, this course stops and the merging course picks up.