GitHub: Your Code in the Cloud

Previously, in Part 5, you caused a merge conflict on purpose, read the markers calmly, and settled the disagreement like an editor-in-chief.

So far, every commit you've made lives in exactly one place: your computer. That's a little lonely — and a little risky. Today your code moves to the cloud, where it's backed up, shareable, and (whisper it) the beginning of your public portfolio.

Git vs. GitHub, honestly

People mix these up constantly, so let's settle it in one honest paragraph. Git is the tool — the time machine installed on your computer that takes snapshots and manages branches. It works entirely offline and belongs to no company. GitHub is a website — a social home where Git repositories live online, with profiles, and collaboration features layered on top. It's the difference between your photos and a photo-sharing site: the camera works fine without the site, but the site is where friends can see the album, leave comments, and get their own copy. (GitHub has cousins — GitLab, Bitbucket — same idea, different neighborhoods.)

You already have a remote

A remote is just a bookmark: a short nickname that points to a repository's URL somewhere else. And here's a fun surprise — you've been using one since Part 4. When you cloned the workshop repo, Git automatically saved where it came from. Look, in your coder000-git-workshop folder:

git remote -v

origin  https://github.com/rahulvyas777/coder000-git-workshop.git (fetch)
origin  https://github.com/rahulvyas777/coder000-git-workshop.git (push)

That word origin looks official, but it's nothing magical — it's simply the default nickname Git gives to "the place I was cloned from." You could rename it mothership and Git wouldn't blink. One nickname, one URL. That's a remote.

The four verbs

Everything you'll ever do with a remote comes down to four commands:

A handy way to remember the last two: pull is really fetch plus a merge — and after Part 5, merges hold no fear for you.

Workshop: your first push

Time for the type-this-see-that moment of the whole series. We'll put your clinic-notes repo — the one you built by hand back in the basics post — on GitHub.

Step 1: get an account. Head to github.com, sign up (it's free), and pick a username you'd be happy to say out loud in a job interview — it will be on everything.

Step 2: create an empty repository. Click the + in the top right → New repository. Name it my-clinic-notes. Important: leave every checkbox unchecked — no README, no .gitignore, no license. We want a perfectly empty shell, because our history already exists on your machine. Click Create repository.

Step 3: introduce the two repos to each other. GitHub now shows you a page of commands; we want the "push an existing repository" pair. In your clinic-notes folder (swap in your username):

git remote add origin https://github.com/YOUR-USERNAME/my-clinic-notes.git
git push -u origin master

The first line saves the bookmark. The second sends every commit you've ever made in that repo up to GitHub — and the -u flag links your local master to the remote one, so from now on a plain git push or git pull knows where to go, no extra words needed.

Now refresh the repository page in your browser. There they are — your files, your commit messages, your history, live on the internet. Go on, click through a commit and see your own changes rendered in green and red. That little shiver of pride? Every developer remembers their first push. Welcome to the club.

Logging in without tears

When you pushed, Git needed to prove you're really you. On Windows and most modern setups, HTTPS plus Git Credential Manager handles this beautifully: a browser window pops up, you approve once, and it's remembered. If that's what happened — wonderful, you're done, skip ahead guilt-free.

The pro move, which you'll meet on every developer's machine eventually, is SSH keys: a matched pair of files that proves your identity without passwords. One careful walkthrough. Generate the pair:

ssh-keygen -t ed25519 -C "you@example.com"

Press Enter through the prompts to accept the defaults. You now have two files in ~/.ssh: id_ed25519 is the private key — it never leaves your machine, you never paste it anywhere, ever. id_ed25519.pub is the public key — this one is safe to share. Open the .pub file, copy its one line, then on GitHub go to Settings → SSH and GPG keys → New SSH key and paste it in. From then on, SSH-flavored URLs work — they look like this:

git@github.com:YOUR-USERNAME/my-clinic-notes.git

Lock and key: GitHub holds the lock (your public key), your machine holds the only key (the private one). Stick with HTTPS for now if it's working — just know the pro door exists.

Say hello with a README

One special file gets the red-carpet treatment: README.md. GitHub renders it right on your repository's front page, like the welcome mat of your project. Create one in clinic-notes with something friendly:

# My Clinic Notes

My practice repository from learning Git, one commit at a time.
Built while following the Git & GitHub series at coder000.com.

Then the rhythm you now know by heart — and notice the shorter push, thanks to -u:

git add README.md
git commit -m "Add a friendly README"
git push

Refresh the page. Your words, nicely formatted, greeting every visitor. That heading syntax is Markdown — a # makes a heading, and that's genuinely enough to start.

And here's the pep talk, because it's true: your GitHub profile quietly becomes a portfolio. Every push adds a green square to your contribution graph, and a wall of green squares tells future employers and collaborators a story no résumé bullet can — this person shows up and builds things. You planted your first square today.

Your code is in the cloud, but so far it's a solo act. In Part 7, we learn how teams actually work together on GitHub: pull requests, code review, and the gentle art of improving each other's work.