Your First Push
Sandpiper's history is about to exist in two places. Three steps: make an empty repository on GitHub, tell your local repository where it lives, and push.
Create it empty
On GitHub, create a new repository called sandpiper. When it offers to add a README, a licence or a .gitignore, decline all three.
This matters more than it looks. Each of those options makes a commit on GitHub's side, which means the two copies immediately have different histories that share no common starting point — and your first push gets rejected for reasons that make no sense to a beginner. Create it empty, and GitHub shows you a page of instructions that are roughly the next two steps.
Name the remote
git remote add origin git@github.com:YOUR-USERNAME/sandpiper.git
origin is the conventional name for "the copy this project belongs to". It is not a keyword — you could call it anything — but everyone calls it origin, so do too.
Use the SSH form above if you set up a key, or the https://github.com/... form if you set up a token. GitHub shows both on the page.
git remote -v
Two lines come back, one for fetching and one for pushing, both pointing at the same place. Nothing has been sent yet; you have written down an address.
Push
git push -u origin main
Git uploads the commits and prints a summary. Your history now exists on GitHub, and refreshing the repository page shows your files.
The -u sets up a connection between your local main and the main on origin, so that Git knows which branch relates to which. That is why every later push is simply:
git push
Look at it
The repository page lists your files. The commits page shows the history from Chapters 2 and 3 — every message you wrote, with your name against it.
This is the moment commit messages stop being a private habit and become public writing. Read the list. If it says anything true and useful, Chapter 2 did its job.
Public or private
Private now, public in Chapter 9, is a sensible order — it gives you time to check the history for anything that should not be there before the whole internet can read it.
The push itself is identical either way. Only who can read the result changes.
What just changed about safety
Until this page, Sandpiper existed in exactly one place. If the laptop had died, the club's website and its whole history would have gone with it.
Now there are two copies, and each one is complete. That is not a backup system in any serious sense — GitHub is one company and one account — but it is the difference between one disk and two, and it is the difference that matters most in practice.
- "
originis a Git keyword." It is a name chosen by convention. You could call it anything; everyone calls itorigin, and consistency is worth more than creativity here. - "Pushing uploads my files." It sends commits. Uncommitted work stays on your laptop, which surprises anyone expecting a folder sync.
- "I should tick 'Add a README' when creating the repository." Not for a repository that already has history locally. That extra commit is the classic cause of a rejected first push.
- "Once pushed, my work is backed up." There are two copies, which is a real improvement. It is not a backup strategy: one account, one company, and anything you delete in both places is gone from both.
- The two-copies picture is what makes every sync command in the next two topics predictable instead of magical.
- Once the history is public, the difference between "fix" and a real commit message stops being theoretical — this is where Chapter 2 gets paid.
- Knowing that push sends commits rather than files explains why "I pushed but my change is not there" almost always means "I did not commit it".
Knowledge Check
Why does this topic insist on creating the GitHub repository empty?
- Because adding a README there creates a commit your history does not share
- Because GitHub charges for repositories that are created with files in them
- Because a README created on GitHub cannot be edited from your own machine
- Because Git refuses to add a remote to a repository that already has commits
What does -u do in git push -u origin main?
- It links your local branch to the one on
origin, so later pushes need no arguments - It uploads the commits urgently, ahead of anything else queued for sending
- It updates the remote repository's settings to match your local configuration
- It uploads uncommitted work as well, so nothing is left behind on the machine
You push, then look at GitHub, and a change you made this morning is missing. What is the likely cause?
- You never committed it, so there was nothing there for the push to send
- The push only sent the most recent commit, and older ones need a second push
- GitHub caches the page, and the change will appear after a few minutes
- The file was too large to upload, so Git silently skipped it during the push
What is origin?
- A conventional name for the remote that your project belongs to
- The first commit in the repository, which every branch traces back to
- The branch that GitHub creates automatically when a repository is made
- A special account permission that allows pushing to a shared repository
You got correct