I used to think git push just meant “save my code to GitHub,” like a fancier Ctrl+S. It’s not that. Understanding the difference between committing and pushing is what finally made Git click for me.

Git actually separates three distinct steps, and each one leaves your work in a different state.

git add stages a change: you’re telling Git “this is going in the next snapshot,” but nothing permanent happens yet. git commit takes everything staged and locks it in as a permanent snapshot in your local history. That’s the part that surprised me: a commit is already permanent the moment you make it. It just lives only on your machine. If your laptop died right after a commit, that snapshot would be gone. Nobody else has ever seen it.

git push is the step that actually shares it. It takes whatever commits exist locally that the remote doesn’t have yet, and uploads them to GitHub. That’s genuinely it: push doesn’t create anything new, it just publishes what you already committed.

This distinction mattered to me for real recently. I was working through a merge conflict on purpose, as practice: two branches that both changed the same line, one to “Python” and one to “Rust.” Merging the first branch was clean. Merging the second is where Git stopped and said, essentially, “I don’t know which of these you want, you decide.” I opened the file, saw the <<<<<<<, =======, and >>>>>>> markers splitting the two versions apart, picked “Python,” and committed the resolution. That merge commit is a little different from a normal one. It has two parents instead of one, since it’s the exact point where two separate histories rejoin into one. You can actually see that shape in git log --graph, two lines folding into a single point.

None of that was shared with anyone until I ran push. Committing is you deciding something is final. Pushing is you deciding other people get to see it.