BlogYour first GitHub commit, and why it feels weird
2026-05-13 · By Kelvin Amoaba

Your first GitHub commit, and why it feels weird

Git looks scary because it uses unfamiliar words for familiar ideas. Here's what's actually happening when you commit and push.

The first time you use git, it feels like a foreign language. You type three commands. None of them sound like English. Somehow your files end up on the internet. You're not entirely sure why, and you're afraid that if you press the wrong key, you'll break something.

This post is for that feeling. I want to demystify what git actually does, in plain English, so the words stop being scary.

The story, in everyday words

Forget git for a moment. Imagine you're writing a scholarship essay in Word.

  1. You edit your document.
  2. You want to save a snapshot of it, so that if you mess things up tomorrow, you can go back to today's version.
  3. You also want to put a copy somewhere — Google Drive, say — so that other people can read it, and so that if your laptop is stolen, your work isn't gone.

That's the entire story of git and GitHub. Nothing more. The only thing that's new is the vocabulary.

  • A snapshot is called a commit.
  • The little message you write to remind yourself what's in the snapshot is called a commit message.
  • The thing that holds all your snapshots on your laptop is called a repository (or "repo").
  • Pushing a copy somewhere others can see it is called, fittingly, a push. The "somewhere others can see it" is called a remote — usually GitHub.

That's it. Five words. Once you've got those, the commands stop feeling random.

What git add actually does

The bit that confuses everyone the first time is that taking a snapshot in git is two steps, not one. You don't just say "snapshot this folder." You say:

  1. "Here are the specific files I want in the next snapshot." — that's git add.
  2. "Okay, take the snapshot now." — that's git commit.

Think of it like packing a box for a friend. git add is putting items into the box. git commit is sealing the box and writing on the side what's inside.

Most of the time, you've changed a few files and you want all of them in the snapshot, so you write:

git add .

The dot means "everything in this folder." Quick and easy. Once you're more practiced, you'll sometimes want to add only one file at a time — for example, when you've made changes for two different reasons and you want one neat snapshot for each. But on your first day, git add . is fine.

What git commit actually does

git commit takes everything you added and bundles it into a single snapshot, with a label.

git commit -m "Add scholarship list filtering by country"

The -m is short for "message." The thing in quotes is your note to future-you. Treat it like a sticky note on the box: short, specific, and useful when you go looking for that box later.

A few examples of what good commit messages look like:

  • "First commit: initial project structure"
  • "Add scholarship list filtering by country"
  • "Fix crash when deadline is missing"

Bad ones:

  • "stuff"
  • "asdf"
  • "update"

You're not writing for me. You're writing for yourself in three weeks, when you're trying to figure out what you changed and why.

The crucial thing to understand: at this point, the snapshot still lives on your laptop only. Nobody else can see it. Your code is not on the internet yet. We have one more step.

What git push actually does

git push is the part where you upload your snapshots to GitHub.

git push

That's the command. When you run it, git looks at all the snapshots you've made on your laptop that aren't yet on GitHub, packages them up, and sends them over. Refresh the GitHub page after a push and your changes are there, with the commit messages you wrote, visible as a little history at the top of the repo.

This is the moment that feels weirdest the first time. You go from "I have a folder on my laptop" to "I have a public link I can paste into a scholarship application", and the in-between step doesn't really feel like anything. You just press enter, and your work is on the internet.

Why the workflow is a loop

Once your project is on GitHub, the rhythm is the same every day:

  1. You edit some files.
  2. git add the ones you want in the next snapshot.
  3. git commit -m "..." to take the snapshot, with a useful label.
  4. git push to upload it.

That's the whole loop. You'll do it dozens of times during the capstone. Eventually, it stops feeling like ritual and starts feeling like brushing your teeth — automatic, quick, and the kind of thing you only notice when you forget.

The thing nobody tells you

Your first commit is small. It's probably one file, a README.md with three lines. The commit message is probably just "First commit". It will feel underwhelming.

It isn't.

For most of human history, the work you did stayed on your machine, your desk, your filing cabinet — visible to nobody. Your first push to GitHub is the moment your work becomes public. Reviewers can read it. Friends can read it. Future employers can read it. Future you, on a new laptop in five years, can read it.

You've stopped hiding your work on your laptop. You've started publishing it.

That's worth more than you think. Welcome.