Stage 1: Getting Started

Getting Started · Lesson 03

Work Like a Real Developer with Git Commands

The four core commands — clone, add, commit, push — and how real teams move code between machines and the cloud.

Getting Started12 min readFree lesson

Audience: Anyone who has completed Lessons 1 and 2 (you have uploaded files by clicking in the GitHub web UI) Time: A 1–2 hour special lesson Prerequisites: The GitHub repository you made in Lessons 1 and 2, and a laptop (Windows/Mac/Linux all work) Outcome: The ability to push code from the terminal with git commit and git push

The Lesson Flow at a Glance

Time Step What you learn
0:00 ~ 0:15 1. What is Git? Version control concepts
0:15 ~ 0:30 2. Installing Git & initial setup User info, authentication
0:30 ~ 0:50 3. Getting a repository (clone) Downloading it to my computer
0:50 ~ 1:15 4. The four core commands (status, add, commit, push) The real workflow
1:15 ~ 1:35 5. Looking at the history (log, diff) Tracing the past
1:35 ~ 1:50 6. Solving the problems you meet often Conflicts, undoing mistakes
1:50 ~ 2:00 7. Wrap-up & next steps A preview of branches

1. What Is Git? (15 min)

Think back to what you did in Lesson 1

Create a file → Upload in the GitHub web UI → Click Commit changes

That was the GitHub website doing a tiny part of what Git can do for you. In this lesson you will learn how to work with Git directly from the terminal.

What exactly is Git?

Git is a program that manages the change history of your files.

Code I wrote today → save "Save Point 1"
Code I edited tomorrow → save "Save Point 2"
Edited again the day after → save "Save Point 3"

When you save every point in time like this:

  • You can go back to any past point at any time
  • You can trace who changed which line, and when
  • Several people can work at the same time and merge without conflicts

Git vs GitHub, one more time

Git GitHub
What it is A program (a tool) A web service (a company)
Where it runs My computer The internet (a server)
Analogy A game's "save" feature A service that backs up your save files to the cloud

Put simply, Git is a tool that runs on your computer, and GitHub is the place on the internet where you share it.

Why learn the terminal?

Clicking in the web UI works too, so why bother with the terminal:

  • Speed: 10 clicks < 1 line of commands
  • Automation: commands can be bundled into scripts
  • Remote servers: company servers often have no GUI
  • The standard: every developer resource and tutorial is written in commands

It feels awkward at first, but once it clicks it is far faster.

2. Installing Git & Initial Setup (15 min)

2-1. Check the installation

First, open a terminal.

  • Windows: search for Git Bash in the Start menu (if it is not there, install it below)
  • Mac: Terminal or iTerm
  • Linux: Terminal
git --version

If you see something like git version 2.40.x, you are good. If it says the command is not found, you need to install it:

  • Windows: https://git-scm.com → download → Next, Next, Next (leave every option at its default)
  • Mac: in the terminal, run xcode-select --install, or go to https://git-scm.com
  • Linux: sudo apt install git (Ubuntu) / sudo dnf install git (Fedora)

2-2. Register your user info (once only)

Every commit records "who wrote it", so you have to set this up first.

git config --global user.name "Alex Kim"
git config --global user.email "[email protected]"

⚠️ Use the same email you signed up to GitHub with! That is how the green squares (your contribution graph) fill in properly on your GitHub profile.

Verify:

git config --global --list

2-3. Set up GitHub authentication

Pushing to GitHub from the terminal requires authentication. Passwords are no longer used; you use a PAT (Personal Access Token) or an SSH key.

Recommended for beginners: PAT

  1. GitHub → profile in the top right → Settings
  2. Developer settings at the very bottom of the left sidebar
  3. Personal access tokens → Tokens (classic) → Generate new token (classic)
  4. A name in Note (for example, my-laptop)
  5. Expiration: 90 days, or No expiration
  6. Permissions: checking only repo is enough
  7. Generate token → copy the token that appears right away (you will never see it again!)

Later, you will type this token instead of a password when you push. Type it once and your OS remembers it.

💡 SSH keys are more convenient in the long run, but at the beginner stage PAT is more intuitive.

3. Getting a Repository — clone (20 min)

3-1. What is clone?

It means copying an entire repository from GitHub down to your computer.

[the my-website repository on GitHub] ──clone──> [the my-website folder on my computer]

3-2. Hands-on: clone the repository you made in Lesson 1

On GitHub, go to your my-website repository page → the green < > Code button → the HTTPS tab → copy the URL.

The URL looks like this:

https://github.com/alex-dev/my-website.git

Now, in the terminal, move to the folder where you want to work:

cd ~/Desktop      # Mac/Linux
cd C:/Users/yourname/Desktop   # Windows (Git Bash)

Run the clone:

git clone https://github.com/alex-dev/my-website.git

(replace the URL with your own)

Go into the folder:

cd my-website
ls          # list the files (Mac/Linux)
dir         # list the files (Windows)

If you can see index.html, README.md, and so on, you succeeded.

3-3. Commands people often mix up

Command What it does
pwd Which folder you are in right now
ls (Mac/Linux) / dir (Windows) The list of files in the current folder
cd folder-name Go into that folder
cd .. Go up to the parent folder
cd ~ Go to your home directory
clear Clear the screen

4. The Four Core Commands — status, add, commit, push (25 min)

This is the heart of the real workflow. Knowing just these four covers 90% of the work.

4-1. The workflow at a glance

[Edit a file]
    ↓
git status     ← see what changed
    ↓
git add filename  ← choose the files to commit
    ↓
git commit -m "message"  ← create a save point
    ↓
git push       ← upload to GitHub
    ↓
[Vercel deploys automatically]

4-2. git status — see the current state

git status

It tells you which files have been modified, added, or deleted. Build the habit of typing git status first whenever you feel stuck.

Example output:

Changes not staged for commit:
  modified:   index.html

Untracked files:
  about.html
  • modified: an existing file was changed
  • Untracked: a new file that Git does not know about yet

4-3. git add — choose the files to commit

git add index.html       # only a specific file
git add .                # every changed file

💡 Why is this step here? Even if you changed 10 files, you may want to commit only 5 of them. add is the step where you choose "the files to include in this commit".

4-4. git commit — create a save point

git commit -m "Change the header color to blue"

After -m comes a message that summarizes the change in one line. Later, that message is the clue you follow when tracing the history.

Good commit messages

  • ✅ Add hover effect to the login button
  • ✅ Adjust the font size on the main page

Bad commit messages

  • ❌ Fixed it
  • ❌ asdf
  • ❌ update

4-5. git push — upload to GitHub

git push

The first time, you need to authenticate.

  • Username: your GitHub username
  • Password: the PAT you created earlier (not your GitHub password)

If it succeeds, you will see the changes when you refresh the repository page on GitHub. And Vercel automatically starts a new build.

4-6. Practice scenario

Open index.html and change a single character. Then:

git status
git add index.html
git commit -m "Edit the welcome message"
git push

GitHub repository → check that the change is there → Vercel dashboard → a new deployment is running → refresh the site → it changed!

This is how real developers work.

5. Looking at the History — log, diff (20 min)

5-1. git log — the list of past commits

git log

Every commit so far is listed, newest first.

commit a1b2c3d4...
Author: Alex Kim <[email protected]>
Date:   Fri May 7 14:30 2026

    Edit the welcome message

Press q to get out.

One line per commit (used more often in practice)

git log --oneline

a1b2c3d Edit the welcome message
e5f6g7h Add the card layout
i9j0k1l First commit

5-2. git diff — check what changed

For when you want to see, after editing and before committing, "what exactly did I change?"

git diff              # changes not added yet
git diff --staged     # changes already added

Red (-) marks deleted lines, green (+) marks added lines.

5-3. git show — look at one commit in detail

git show a1b2c3d

You can see in detail which changes that commit contains.

6. Solving the Problems You Meet Often (15 min)

6-1. "I just wrote the wrong commit message"

If you have not pushed yet:

git commit --amend -m "the correct message"

If you already pushed: leave it. Trying to fix a commit message with a force push is how accidents happen.

6-2. "I want to throw away my edits and go back to the last commit"

git restore filename       # only a specific file
git restore .              # every file

⚠️ This command cannot be undone. Make sure the changes are really safe to discard before you use it.

6-3. "I added the wrong thing"

git restore --staged filename

The add is undone, but the file changes stay exactly as they are.

6-4. "My push was rejected"

If you see a message like this:

! [rejected] main -> main (fetch first)

Cause: GitHub has changes that your computer does not have (you edited something directly in the web UI, or pushed from another computer)

Fix:

git pull
git push

pull is the command that brings GitHub's changes down to your computer.

6-5. "I got a merge conflict"

It happens when your change and GitHub's change modified the same line in different ways.

Open the file and you will see something like this:

<<<<<<< HEAD
the content on my computer
=======
the content on GitHub
>>>>>>> origin/main

Edit it yourself to decide which side to keep (or to keep both), delete every one of the marker symbols (<<<, ===, >>>), and then:

git add .
git commit -m "Resolve the conflict"
git push

💡 At the beginner stage you work alone, so conflicts are rare. If one does happen, do not panic, just follow the steps above.

7. Wrap-Up & Next Steps (10 min)

The commands you learned today

# Initial setup (once only)
git config --global user.name "Your Name"
git config --global user.email "[email protected]"

# Get a repository
git clone <URL>

# The four core commands (every time)
git status
git add <file>
git commit -m "message"
git push

# View history
git log --oneline
git diff

# Get changes
git pull

# Undo
git restore <file>
git restore --staged <file>

Once you are comfortable with just this much, you have covered 90% of what a solo developer does.

The workflow on one page

GitHub repository
   │
   │ git clone   (the first time only)
   ↓
Write code on my computer
   │
   │ git status   (what changed?)
   │ git add .    (this is what I'll commit)
   │ git commit -m "..."  (save point)
   │ git push     (upload to GitHub)
   ↓
GitHub repository (updated)
   │
   │ Vercel detects it automatically
   ↓
Homepage redeployed automatically ✨

Good things to learn next

When What Why
Next week Branches To experiment safely
After that GitHub Pull Request The basis of collaboration
In a month JavaScript basics Dynamic web pages
In two months VS Code Git integration Faster with a GUI

Recommended learning resources (all free)

One last word

Commands feel awkward at first. But if you push once a day for just one week, your hands will remember them. It is fine to make mistakes. Git is designed so that almost every mistake can be undone.

Starting today, push every code change from the terminal. That is what makes you a real developer. 🎉

Appendix A. Frequently Asked Questions (FAQ)

Q. I lost my PAT. Issue a new one. Not even GitHub can show the token to you again. Create a new one, delete the old entry in your OS credential manager (Windows: Credential Manager, Mac: Keychain), and try again.

Q. It asks for a password every time I git push. After you enter the PAT once, the OS stores it. If it is not stored, enable caching with this command:

git config --global credential.helper store

(Note: it is stored in plain text. Not recommended on a shared computer.)

Q. cd will not take me into a folder that has a space in its name. Wrap it in quotes: cd "My Documents"

Q. Git is great, but there are too many commands. Is there no GUI?

Still, learning the commands first and using a GUI later is more powerful in the long run. A GUI is only running the commands for you, so if you do not know the principles, it is more frustrating when you get stuck.

Q. I see something called .gitignore. What is it? It is a file that tells Git "do not track this file". You use it to exclude things like secret keys, build output, and OS system files (.DS_Store, Thumbs.db). We will cover it in the next lesson.

Appendix B. Tips for Instructors

  • Explain the OS differences up front. Git Bash on Windows, Terminal on Mac/Linux. The commands are almost identical, but the path separator (/ vs \) and a few commands (ls vs dir) differ.
  • The PAT step is where people get stuck most. The GitHub UI changes often, and choosing token permissions is confusing. Re-run it yourself right before the lesson and refresh your screenshots.
  • Make the terminal font bigger. Demoing at the default size is invisible from the back row. 18–20 pt is recommended.
  • Have them repeat git status between every command. "The habit of checking what you just did" is the heart of self-directed learning.
  • Keep conflict resolution light. Merge conflicts overwhelm beginners. Just mention that they can happen; do the live demo in the later collaboration lesson.
  • If you make a typo during a live demo, do not panic; just show it as it is. "How to read an error message" is the skill that really needs teaching.

Written: 2026-05 / License: free to modify and redistribute

Example files

Complete, runnable files used in this lesson. Copy them into your project and experiment.

.gitignore.exampleConfig
# Example .gitignore file
# Rename this file to .gitignore (with the leading dot!) and keep it at the repository root for it to take effect.
# List the file and folder patterns that Git should not track.

# ===== OS system files =====
.DS_Store           # Mac
Thumbs.db           # Windows
desktop.ini

# ===== Editor settings =====
.vscode/
.idea/
*.swp

# ===== Build output =====
dist/
build/
node_modules/

# ===== Environment variables / secret keys =====
.env
.env.local
*.key
secrets.json

# ===== Logs =====
*.log
npm-debug.log*
git-cheatsheet.mdMarkdown
# Git Command Cheatsheet

Every command covered in Lesson 3, collected on one page. Print it out and stick it on your desk.

---

## Initial Setup (once only)

```bash
git config --global user.name "Your Name"
git config --global user.email "[email protected]"
git config --global --list           # check your settings
```

## Getting a Repository

```bash
git clone <URL>                      # copy a GitHub repository to my computer
```

## The Four Core Commands (used every day)

```bash
git status                           # check the current state of changes
git add <file>                       # stage one specific file for commit
git add .                            # stage every changed file for commit
git commit -m "message"              # create a save point
git push                             # upload to GitHub
```

## Fetching / Syncing

```bash
git pull                             # bring down the latest changes from GitHub
git fetch                            # fetch only (no merge)
```

## Viewing History

```bash
git log                              # commit list (detailed)
git log --oneline                    # commit list (one line each)
git log --oneline --graph            # as a graph
git diff                             # changes (before add)
git diff --staged                    # changes (after add)
git show <commit-id>                 # look at one commit in detail
```

## Undoing

```bash
git restore <file>                   # discard the changes to a file
git restore --staged <file>          # unstage the add (the changes are kept)
git commit --amend -m "new message"  # edit the last commit message (before push only)
```

## File State Flow

```
[Working Directory]    git add    [Staging Area]    git commit    [Local Repository]    git push    [GitHub]
   edit files        ────────>    ready to commit  ──────────>    committed            ────────>    on the remote
                                                                                       git pull
                                                                                      <────────
```

---

## Reading the Messages You Meet Often

| Message | Meaning | What to do |
|---|---|---|
| `nothing to commit, working tree clean` | Nothing has changed | Normal |
| `Untracked files` | A new file Git does not know about | Add it with `git add` |
| `Changes not staged for commit` | Modified but not added | `git add` |
| `Changes to be committed` | Already added | `git commit` |
| `! [rejected] ... (fetch first)` | The remote has new changes | `git pull`, then `git push` |
| `CONFLICT (content): ...` | Merge conflict | Edit the file yourself, then `git add` → `git commit` |

---

## The Magic One-Liner (when you are stuck)

```bash
git status
```

**Whatever you are stuck on, start with this.** Git kindly tells you what to do next.

Assignment

Assignment 03 — Git command drills

Practise the four commands you will use every day, plus the history tools.

Setup

mkdir git-drills && cd git-drills
git init

Drill 1 — status, add, commit

  1. Create index.html with a heading.
  2. Run git status and identify untracked files.
  3. Stage only index.html, then commit with a message that completes "This commit will…".
  4. Run git status again and confirm a clean tree.

Drill 2 — a second and third commit

  1. Add style.css and commit.
  2. Edit the heading in index.html and commit.
  3. Run git log --oneline and confirm three commits.

Drill 3 — diff

  1. Change one line without committing.
  2. Run git diff and explain the - and + lines.
  3. Stage the change, run git diff --staged, then commit.

Drill 4 — push

  1. Create an empty GitHub repository.
  2. Add the remote and push with -u.
  3. Change a file, commit and push again.
  4. Confirm both commits appear on GitHub.

Drill 5 — undo without losing work

  1. Edit a file and run git restore <file> — the edit is gone.
  2. Edit again, stage it, then git restore --staged <file> — the edit remains.
  3. Commit, then git revert HEAD and confirm a new revert commit.

Write-up

GIT-NOTES.md:

  • What is the difference between the working tree, the staging area and the repository?
  • When would you use git restore versus git revert?
  • What does -u do on the first push?

Done when

  • The remote shows every commit.
  • git log --oneline --graph is readable.
  • You can explain each command without looking it up.

Learn this lesson with a mentor

Work through the Build Your Homepage series on your own, or join a guided cohort at our Pitampura campus and online.

Enroll nowStage overview
Call NowEnroll Now