Your machine vs. the shared copy

Here’s something that surprises almost everyone: every commit you’ve made so far is private. It lives on your computer and nowhere else. Your teammate can’t see it. A second computer of your own can’t see it. Not until you push.

Committing saves your work locally. Pushing publishes it to the shared copy everyone else can see.

There are two copies of the project. Yours, on your machine (local), and the shared one — usually on GitHub — that the whole team pulls from (the remote). This is the same local-vs-elsewhere split you met in Lesson 3.9. Commits pile up locally; git push sends them up to the remote. The reverse, git pull, brings teammates’ commits down to you.

Pushing is a different kind of door

A local commit is completely yours. You can rewrite it, delete it, redo it — nobody’s seen it, so there’s no harm done.

Pushing changes that. The moment your commits hit the shared copy, other people can pull them, build on top of them, and depend on them. You can’t cleanly un-ring that bell. That’s a one-way door, the kind you learned to slow down for in Lesson 6.4.

It’s also exactly why a pushed secret (from Lesson 8.2) is compromised: the moment it leaves your machine, you have to assume someone has it.

Pushing isn’t dangerous — you’ll do it constantly. But it’s the line between “private draft on my laptop” and “out in the world.” Give it the same half-second of attention you’d give any one-way door.

The Claude way

push this branch

Claude runs it. The first time you push a brand-new branch, Claude also sets it up on the remote for you — no setup ritual to memorize. And nothing leaves your machine until you say the word: silence means it’s still just yours.

What’s next

Pushing puts your branch on GitHub — but it sits off to the side. The real project (main) still doesn’t have your changes. To propose folding them in, you open a pull request. Next.