🚀 Basic Git Commands & Pushing to GitHub

What Is Git & Version Control?

Version control is a system that records changes to your files over time so you can recall any earlier version, see who changed what, and combine work from many people without stepping on each other. Git is the version-control tool that runs the software world; GitHub is a website that hosts Git repositories online so you can back them up and collaborate.

Imagine writing a book with several co-authors. Without a system you would email chapter_final.doc, then chapter_final_v2.doc, then chapter_final_REALLY_final.doc, and nobody would know which is current. Git replaces that chaos with a single, orderly history: every save is a labeled snapshot you can return to, compare against, or branch away from. That is the difference between hoping you didn't lose work and knowing you can always get it back.

Here is the shape of what you're about to build — the path a change takes from the file you're editing all the way to GitHub:

The rest of this tutorial walks each arrow, left to right.

Install & First-Time Setup

Before Git can track anything, it needs to exist on your machine and know who you are. Every snapshot you save is stamped with a name and email so collaborators can see who made each change.

1. Install Git

Download it from the official site, git-scm.com/downloads. On macOS it often comes with the developer tools; on Windows the installer includes "Git Bash," a terminal you can use for every command in this course. Confirm the install:

git --version
# git version 2.43.0   (any recent 2.x is fine)

2. Tell Git who you are

Do this once per computer. The --global flag applies it to every repository you'll ever create on this machine.

git config --global user.name "Ada Lovelace"
git config --global user.email "ada@example.com"

Why it matters: these two values are baked into every commit. Use the same email you'll register on GitHub so your contributions link up to your profile automatically.

3. Set main as your default branch

Modern Git and GitHub use main as the primary branch name (older tutorials say master). Make new repositories start on main so your local and remote names always agree:

git config --global init.defaultBranch main

git config --global --list
# user.name=Ada Lovelace
# user.email=ada@example.com
# init.defaultbranch=main

Creating a Repository: git init

A repository (or "repo") is just a normal project folder with an extra hidden .git subfolder inside it. That hidden folder is Git's brain — it stores your entire history. Turning any folder into a repo takes one command.

# Make a project folder and move into it
mkdir portfolio-site
cd portfolio-site

# Turn this folder into a Git repository
git init
# Initialized empty Git repository in /home/you/portfolio-site/.git/

What just happened: Git created the hidden .git/ directory. Your files are untouched — nothing is being tracked yet. You only run git init once per project; from now on Git watches this folder for changes.

Let's add a file to track:

echo "<h1>Hello, world</h1>" > index.html

The Save Loop: add & commit

Saving in Git is a deliberate two-step move, and beginners often trip on the fact that it isn't one. First you stage the changes you want to include (git add), then you commit them (git commit) — permanently recording a snapshot with a message describing what changed.

Think of it like packing a box to ship. git add is choosing which items go in the box; git commit is sealing it, labeling it, and putting it on the shelf of your project's history. Staging first lets you commit some changes now and others later, so each snapshot tells a clean story.

Step 1 — Stage with git add

git add index.html    # stage one specific file
git add .             # or stage every changed file in the folder

Explanation: Staging marks changes as "these belong in my next snapshot." Nothing is saved to history yet — you're just filling the box.

Step 2 — Commit with git commit

git commit -m "Add homepage heading"

Explanation: This seals the snapshot and stamps it with your identity, a timestamp, and the message after -m. That message is a note to your future self — write it in the present tense describing what the change does ("Add login form"), not what you did ("added stuff").

[main (root-commit) a1b2c3d] Add homepage heading
 1 file changed, 1 insertion(+)
 create mode 100644 index.html

Inspecting: status & log

Two commands answer "where am I?" and "what have I done?" You'll run git status constantly — think of it as glancing at a dashboard before you drive.

git status — what's changed right now

git status

On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
        modified:   index.html

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        styles.css

no changes added to commit (use "git add" and/or "git commit -a")

This tells you exactly what is modified, what is staged, and what Git isn't tracking yet — and it even prints the command you probably want next. When you're stuck, git status is almost always the answer.

git log — your project's history book

git log
git log --oneline    # compact, one commit per line

e4f5g6h Add contact section
a1b2c3d Add homepage heading

Each line is a snapshot you can return to. The short code at the front (like a1b2c3d) is the commit's unique ID — you'll use those IDs later to compare versions or travel back in time.

Pushing to GitHub

So far everything lives only on your laptop. To back it up and share it, you connect your local repo to a remote — a copy hosted on GitHub — and push your commits up to it.

Step 1 — Create an empty repo on GitHub

On github.com/new, give the repository a name (for example portfolio-site) and click Create repository. Leave "Add a README" and ".gitignore" unchecked — you want it completely empty so your local history transfers cleanly.

Step 2 — Connect the remote

GitHub shows you the repository's URL. Register it locally under the conventional nickname origin:

git remote add origin https://github.com/yourname/portfolio-site.git

# Confirm it's linked
git remote -v
# origin  https://github.com/yourname/portfolio-site.git (fetch)
# origin  https://github.com/yourname/portfolio-site.git (push)

Explanation: origin is just a friendly alias for that long URL, so you can type git push origin instead of the full address every time.

Step 3 — Push

git push -u origin main

Enumerating objects: 6, done.
Writing objects: 100% (6/6), 512 bytes | 512.00 KiB/s, done.
To https://github.com/yourname/portfolio-site.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

Explanation: The -u flag ("set upstream") links your local main to the remote main, so from now on you can just type git push with no extra arguments. Refresh the GitHub page — your files are live.

Everyday Updates

Now that the connection exists, the daily rhythm is short. Whenever you've made changes worth saving:

git add .
git commit -m "Add project cards to homepage"
git push

That's the entire loop you'll repeat thousands of times: edit → add → commit → push. Stage what changed, snapshot it with a clear message, and send it up to GitHub.

Practice & Quiz

# 1. Create and enter a project folder
mkdir first-repo && cd first-repo

# 2. Turn it into a Git repository
git init

# 3. Add a file and snapshot it
echo "# My First Repo" > README.md
git add README.md
git commit -m "Add README"

# 4. (On github.com) create an EMPTY repo named first-repo

# 5. Connect the remote and push
git remote add origin https://github.com/yourname/first-repo.git
git push -u origin main

echo "More content" >> README.md
git add README.md
git commit -m "Expand README with description"

echo "Even more" >> README.md
git add README.md
git commit -m "Add usage section"

git log --oneline
# 3 lines, newest first — each one a snapshot you can return to

Best Practices & Pitfalls

✅ Do

• Set your user.name and user.email before your first commit
• Write commit messages that describe the change: "Add contact form," not "update"
• Run git status often — it tells you exactly what state you're in
• Commit small, logical chunks rather than one giant end-of-day dump
• Keep new GitHub repos empty when you plan to push an existing local project into them

❌ Don't

• Run git init in your home directory or Desktop — only inside a project folder
• Commit secrets like API keys or passwords (a .gitignore keeps them out — see the next tutorial)
• Assume a commit uploaded to GitHub — commit is local; you still need git push
• Panic at a rejected first push; it usually means the remote wasn't empty

Summary

📚 Additional Resources

• Pro Git — First-Time Git Setup
• git-scm.com — git commit documentation
• GitHub Docs — Adding locally hosted code to GitHub

🚀 What's Next?

You can now create a repo and push it. Next we go a level deeper into how Git thinks: the staging area, keeping junk out with .gitignore, cloning existing projects, and managing remotes — the daily-workflow mechanics that make the commands above feel effortless.