☁️ GitHub: the cloud copy (push, fetch, pull)

By the end of this page you will know exactly what GitHub is, what push, fetch, and pull really do, and why a "rejected" push is git protecting you, not scolding you.

1Git and GitHub are not the same thing

For eight lessons, everything happened on your Mac. Your photo album of save points lives in your project folder, and it works perfectly with the WiFi off. Time to meet the second word in the course title.

📸 Git is the camera and the album. GitHub is the photo-sharing website. The camera works anywhere, no internet needed. The website is where you upload a copy of the album so other people can see it, comment on it, and add their own photos.

So they are two different things that happen to share a name:

gitGitHub
What it isa program on your Maca website
Works offline?yes, completelyno, it lives online
Its jobkeeps your album of save pointshosts copies of albums so teams can share them
Who owns itno one, it is free open sourceMicrosoft

GitHub also stacks collaboration tools on top of the hosting: code reviews and shared to-do lists, which you will meet in lessons 10 and 11. And GitHub is not the only site like this. GitLab and Bitbucket do the same job. Learn one and you can use them all, because underneath they are all just hosting git albums.

2Two complete albums, not one

Here is the part that surprises people who know Dropbox or iCloud Drive. Those tools often keep the real files in the cloud and leave little placeholder stubs on your disk. Git does not work that way at all.

Your Mac holds the entire album: every photo, every sticky note, the whole chain back to the very first save point. GitHub holds its own entire copy of the same album. Two complete albums, one on your desk and one in the cloud. If GitHub vanished tomorrow, you would still have everything. If your Mac caught fire, GitHub would still have everything. That is the whole point.

These are the real save points from your own project, shown living in both places at once:

💻 your Mac main 836f2de finished content db039fb review fixes f30f6b7 todo update the ENTIRE album, every photo ☁️ GitHub: git calls it origin main 836f2de finished content db039fb review fixes f30f6b7 todo update its own ENTIRE copy, not stubs push ⬆ fetch ⬇ pull = fetch ⬇ then merge, in one move

Same beads, same sticky notes, same green main bookmark on both sides. The only question left is how the two albums stay matched. That takes exactly three verbs.

3The three sync verbs, in plain words

You take new photos on your Mac, so sometimes your album is ahead. Teammates upload their photos to GitHub, so sometimes the cloud album is ahead. Three moves keep things in sync: upload mine, download theirs to look, and download theirs and blend them in.

🗣 Git's words for the three moves are "push," "fetch," and "pull." Push uploads your new save points to GitHub. Fetch downloads theirs so you can look, changing nothing of yours. Pull is fetch plus a merge: it downloads theirs AND blends them into your work, in one command.
verbin plain wordsdoes it touch your work?
pushupload my new photos to GitHubno, only GitHub's album changes
fetchdownload their new photos so I can lookno, your files stay exactly as they were
pulldownload their new photos and blend them into mineyes, it is fetch plus the merge from lesson 6

Because pull ends in a merge, it can occasionally raise a conflict. Remember: a conflict is git asking you a question, not an error. You already learned how to answer it, line by line, and nothing gets lost while you decide.

🗣 Three more official words. Any other copy of your album is called a "remote." The default nickname for your main remote, usually the GitHub copy, is "origin." And the first-time download of a whole repo, the entire album in one go, is a "clone": git clone URL.

Q. What is the difference between fetch and pull?

Fetch is the look, pull is the look plus the blend. Pull runs a fetch and then a merge, so it can change your files and can even ask you a conflict question. Fetch never touches your work at all.

4The seatbelt: when push says no

Sooner or later you will push and see this. It looks scary. It is not.

git push
To github.com:you/your-project.git
 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'github.com:you/your-project.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. If you want to integrate the remote changes, use
hint: 'git pull' before pushing again.

Translated into album language: "GitHub has photos you have not seen yet. Download them first." Probably a teammate pushed while you were working. Git refuses to let your upload overwrite save points you never looked at. That is the safety rule: push will never silently destroy work on the other side.

The fix is two commands, and you already know both:

git pull
# download their new photos and blend them with yours
Merge made by the 'ort' strategy.
git push
   4e19c72..8c2d1aa  main -> main

Pull, then push. If the pull raises a conflict question, answer it the way lesson 7 taught you, then push. This message is not an error. It is a seatbelt clicking shut.

⚠️ If the internet tells you to add --force, pause. A forced push cuts the seatbelt and can overwrite other people's save points on GitHub. As a beginner you never need it. Pull first, blend, push. That path is always safe.

Check yourself: your push was just rejected. What happened, and what do you do?

GitHub has save points you have not downloaded yet, most likely because a teammate pushed first. Git protects their work by refusing your upload. You run git pull to download and blend their photos with yours, resolve any conflict question if one comes up, and then git push again. Nothing was lost on either side at any point.

5You already use this every day

📱 It works like photo sync on your phone. Your phone holds the photo album, and the cloud holds a copy of the same album. Take a picture and it uploads. A picture taken on your iPad downloads to your phone. Upload and download keep the two albums matched, and you never think about it. Git is the same picture, with one twist: when two people have both edited the album, blending the two versions sometimes needs a human to answer a question. That is the merge, and that is the only part the photo cloud never asks of you.

So if syncing photos has never frightened you, syncing save points should not either. Push is upload. Fetch is download to look. Pull is download and blend. The vocabulary is new, the habit is one you already have.

6Field trip: read a real repo, no account needed

You do not need an account, a password, or even Terminal for this one. GitHub shows public albums to anyone, and you can already read every part of the page.

⌨️ Try it yourself

Open your browser and visit a famous public repo, for example the album of git itself:

github.com/git/git
# yes, git keeps its own history in git

Now find your three old friends on the page:

1. The file list in the middle is the latest photo: the project exactly as it looks at the newest save point.
2. The commits count near the top, click it, is the photo album: the whole chain of beads, newest first, just like git log.
3. The branch dropdown on the left is the box of bookmarks. On this repo it says master, the older name for the default bookmark, which the git project still uses. Pick a different one and the file list jumps to where that bookmark is clipped.

Nothing on this page is new to you. It is the same album, the same chain, the same bookmarks, just drawn by a website instead of your Terminal.

🧠 If you remember one thing: your Mac and GitHub each hold a complete copy of the album: push sends yours up, fetch downloads theirs to look, pull downloads and blends, and a rejected push is a seatbelt, never an error.