Chapter 4 Sidequest
Sidequest: Your First GitHub Push
Setting up GitHub and pushing your first repository to the cloud.
- About 20 minutes
- An email address
- A phone number (for 2FA)
Your Git repository lives on your computer right now. That's fine—but what if your hard drive dies? What if you want to work on your project from a different computer?
That's where remote repositories come in. GitHub is the most popular place to store them—like a cloud backup for your code.
Step 1: Create a GitHub Account
Head over to github.com and click "Sign up." Pick a username you won't be embarrassed by in five years—this is your professional identity now.
- Keep it simple and readable
- Avoid numbers if possible (unless they're meaningful)
- This will be part of your URLs forever
Good: maxpower, max-power, themaxpower
Avoid: xXxMaxPower2024xXx, coolhacker9000
You'll need to verify your email and set up two-factor authentication (2FA). Yes, it's annoying. Yes, it's necessary. People try to hack into GitHub accounts all the time because that's where the code lives.
Step 2: Create a Repository on GitHub
Once you're in, click the green "New" button to create a repository.
Click "Create repository." You'll see a page with instructions. We want the section that says "push an existing repository from the command line."
Step 3: Set Up SSH Keys
Before you can push code to GitHub, you need to prove you're you. The most secure way is with SSH keys—a pair of files that act like a really long password.
What's SSH?
"Secure Shell. It's how computers talk to each other securely. Right now, we just need to create a key pair—one private key (never share this) and one public key (you give this to GitHub)."
$ ssh-keygen -t ed25519 -C "your-email@example.com"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/max/.ssh/id_ed25519):
It'll ask where to save the key—just press Enter for the default location. It'll ask for a passphrase—pick something you can remember, or leave it blank (less secure, but simpler for learning).
Now you have two files:
~/.ssh/id_ed25519— Your private key. Never share this.~/.ssh/id_ed25519.pub— Your public key. This goes on GitHub.
$ cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your-email@example.com
Select and copy the entire output (it starts with ssh-ed25519 and ends with your email).
Now go to GitHub → Settings → SSH and GPG Keys → New SSH Key. Paste it in, give it a name like "My laptop," and save.
$ ssh -T git@github.com
Hi username! You've successfully authenticated, but GitHub does not provide shell access.
Hi username! You've successfully authenticated, but GitHub does not provide shell access.
That message means it worked! You're connected.
Step 4: Connect Your Local Repo to GitHub
Now we tell your local Git repository where the remote copy lives.
$ cd ~/minecraft-server
$ git remote add origin git@github.com:YOUR-USERNAME/minecraft-server.git
Replace YOUR-USERNAME with your actual GitHub username. The URL should match what GitHub showed you after creating the repository.
$ git push -u origin main
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Branch 'main' set up to track remote branch 'main' from 'origin'.
Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 8 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (5/5), 523 bytes | 523.00 KiB/s, done. Total 5 (delta 0), reused 0 (delta 0) To github.com:YOUR-USERNAME/minecraft-server.git
- new branch main -> main Branch 'main' set up to track remote branch 'main' from 'origin'.
It's on the internet! I can see it on GitHub!
Refresh your GitHub repository page. Your files are there. Every commit you made is there. The full history, backed up in the cloud.
Step 5: The Daily Workflow
From now on, after you commit locally, push to keep GitHub in sync.
$ git add .
$ git commit -m "Add backup service"
[main abc1234] Add backup service
$ git push
Enumerating objects: 3, done.
And if you ever work from a different computer (or want to start fresh), you can clone the repository:
$ git clone git@github.com:YOUR-USERNAME/minecraft-server.git
Cloning into 'minecraft-server'...
done.
- Private: Only you can see it. Good for personal projects.
- Public: Anyone can see (but not change) your code. Good for sharing.
You can change this setting anytime in the repository settings.
When Things Get Complicated
Once you have code in two places—your computer and GitHub—things can get tangled. Here are the scenarios that will definitely happen to you eventually.
"Someone Changed the File on GitHub!"
Maybe you edited a file directly on GitHub's website (it has an editor). Maybe you worked on a different computer. Now you try to push and Git says no:
To github.com:YOUR-USERNAME/minecraft-server.git ! rejected main -> main (fetch first) error: failed to push some refs to 'github.com:YOUR-USERNAME/minecraft-server.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally.
What?! I just want to push my changes!
"Git is protecting you," I said. "There are changes on GitHub that you don't have. If you just pushed, you might overwrite them. First, you need to pull those changes down."
$ git pull
remote: Enumerating objects: 3, done.
Already up to date.
Git will try to merge the remote changes with your local changes. If the changes were in different files, it just works. If they're in the same file... you might get a merge conflict. We'll deal with that in a second.
But there's a cleaner way to do this: pull --rebase.
$ git pull --rebase
Already up to date.
"What's the difference?" Max asked.
"Regular git pull creates a 'merge commit'—a record that you combined two histories. It's fine, but it clutters your log. git pull --rebase pretends your changes happened after the remote changes. Cleaner history, same result."
"For a personal project, either works. But as you get more advanced, you'll appreciate rebase."
"Git Won't Let Me Pull Because I Have Uncommitted Changes!"
This one's common. You edited a file but didn't commit. Now you try to pull and Git complains:
error: Your local changes to the following files would be overwritten by merge: docker-compose.yml Please commit your changes or stash them before you merge.
Stash? What's stash?
"Stash is like a temporary pocket. You can stuff your uncommitted changes in there, do what you need to do (like pull), then take them back out."
$ git stash
Saved working directory and index state WIP on main: a1b2c3d Working Minecraft server setup
Saved working directory and index state WIP on main: a1b2c3d Working Minecraft server setup
Your changes are now safely stored. Your working directory is clean.
$ git pull
Already up to date.
$ git stash pop
On branch main
Changes restored.
Dropped refs/stash@{0}
"Pop" takes the most recent stash and applies it to your current files. Your changes are back, combined with whatever you pulled.
git stash # Hide uncommitted changes
git stash pop # Bring them back and remove from stash
git stash list # See all stashed changes
git stash drop # Delete the most recent stash
git stash apply # Bring them back but keep in stash too
"I Messed Everything Up—How Do I Start Over?"
Sometimes you just want to throw away everything and get back to the last commit. Or the last pushed commit. Git has several "reset" options:
# Soft reset: undo commit, keep changes staged
git reset --soft HEAD~1
# Mixed reset (default): undo commit, keep changes but unstaged
git reset HEAD~1
# Hard reset: undo commit AND throw away all changes
git reset --hard HEAD~1
HEAD~1 means "one commit before HEAD (your current position)."
--hard is dangerous! It throws away work. Only use it when you're sure.
"But what if I already pushed?" Max asked. "And I want to match what's on GitHub?"
$ git fetch origin
$ git reset --hard origin/main
HEAD is now at a1b2c3d Working Minecraft server setup
"This throws away all your local changes and makes your folder match exactly what's on GitHub. It's the 'I give up, start fresh' option."
"Use it when you've made a mess and just want a clean slate. But be aware—any uncommitted work is gone forever."
What About Passwords?
Remember how we talked about .gitignore and never committing secrets? This is extra important now that your code is on the internet.
Before you push, always check:
$ git status
On branch main
nothing to commit, working tree clean
$ git diff --cached
If you accidentally push a password or API key to GitHub:
- Change the secret immediately. Assume it's compromised.
- Don't just delete the file—it's still in your Git history.
- For serious cases, you need to rewrite history (ask for help with this).
Prevention is easier than cleanup. Check before you push.
Summary
"That's a lot," Max said.
"It is. But here's the thing—you won't remember all of this. Nobody does. What matters is knowing that solutions exist. When you hit an error, you'll think 'oh right, stash' or 'I need to pull first' and look up the command."
"Git is like that. It's a toolbox. You learn the tools as you need them."
You've set up GitHub and learned to handle common situations:
- SSH keys for secure authentication
- Pushing and pulling code
- Using stash when you have uncommitted changes
- Resetting when things go wrong
# Quick reference
git push # Send commits to GitHub
git pull # Get commits from GitHub
git pull --rebase # Get commits, cleaner history
git stash # Temporarily hide changes
git stash pop # Bring changes back
git reset --hard origin/main # Match GitHub exactly (nuclear)