Level 1 — Absolute beginner

Objective

Build a small personal repository from nothing and make three commits, watching how each file moves through Git's areas. By the end you will have created files and a folder, staged and committed them, read the history, and seen the most common beginner error message on purpose.

Starting state

• Git is installed and configured with your name and email (First-time configuration). Check with git config --global user.name.
• A terminal is open (The terminal for humans). On Windows use Git Bash, which comes with Git, so the commands below work unchanged.
• Any text editor (VS Code is fine). Where the lab creates a file with printf, you may instead create it in your editor and type the same text; the result is identical.

You do not need the playground or a GitLab account for this lab. Everything stays on your computer.

Warm-up: the same commands, in a simulator

If you would rather see what each command does before running it for real, this simulator models the same sequence. It cannot touch your files.

Instructions

1. Create a folder and go into it. Start from your home folder so you always know where the practice folder is.

   $ cd ~
   $ mkdir git-practice
   $ cd git-practice
   $ pwd

   Copy

   /Users/you/git-practice

   Checkpoint: the path ends in git-practice. On Windows it looks like /c/Users/you/git-practice.

2. Turn the folder into a repository.

   $ git init

   Copy

   Initialized empty Git repository in /Users/you/git-practice/.git/

   Git created a hidden .git folder; that is the repository. The folder itself is now your working tree. If the output also prints hints about a branch named master, run git branch -m main now and set the default for the future with git config --global init.defaultBranch main.

3. Look at an empty repository.

   $ git status

   Copy

   On branch main
   
   No commits yet
   
   nothing to commit (create/copy files and use "git add" to track)

   Checkpoint: On branch main and No commits yet.

4. Create your first file. A README is the traditional first file: it tells visitors what the folder is.

   $ printf '# My Git practice\n' > README.md
   $ git status

   Copy

   On branch main
   
   No commits yet
   
   Untracked files:
     (use "git add <file>..." to include in what will be committed)
   	README.md
   
   nothing added to commit but untracked files present (use "git add" to track)

   The file exists on disk, but Git has never been told about it: it is untracked.

5. Stage the file. This copies the change into the staging area.

   $ git add README.md
   $ git status

   Copy

   On branch main
   
   No commits yet
   
   Changes to be committed:
     (use "git rm --cached <file>..." to unstage)
   	new file:   README.md

   Checkpoint: new file: README.md under Changes to be committed. The hint mentions git rm --cached instead of git restore --staged only because there is no commit yet; after the first commit the hint changes.

6. Make your first commit. The message says what this snapshot is.

   $ git commit -m "Add README"

   Copy

   [main (root-commit) 548a37c] Add README
    1 file changed, 1 insertion(+)
    create mode 100644 README.md

   root-commit means the very first commit of the repository. 548a37c is the first seven characters of the commit's hash; yours will be different, and that is normal. Run git status again: it now says nothing to commit, working tree clean.

7. Create a folder with a file, and edit the README. Two changes of different kinds at once.

   $ mkdir notes
   $ printf '# Day 1\n\nToday I created my first repository.\n' > notes/day-1.md
   $ printf '\nThis repository is where I practice Git.\n' >> README.md
   $ git status

   Copy

   On branch main
   Changes not staged for commit:
     (use "git add <file>..." to update what will be committed)
     (use "git restore <file>..." to discard changes in working directory)
   	modified:   README.md
   
   Untracked files:
     (use "git add <file>..." to include in what will be committed)
   	notes/
   
   no changes added to commit (use "git add" and/or "git commit -a")

   Checkpoint: README.md is modified (Git knows it and sees a difference) and notes/ is untracked (Git shows the folder as one line because everything inside is new). Note the >> in the third command: it appends to the file instead of replacing it.

8. Stage everything and look again.

   $ git add .
   $ git status

   Copy

   On branch main
   Changes to be committed:
     (use "git restore --staged <file>..." to unstage)
   	modified:   README.md
   	new file:   notes/day-1.md

   git add . stages every change in the current folder and below. It is convenient, and it is also how unwanted files sneak into commits — always read the status after it.

9. Second commit.

   $ git commit -m "Add first note and describe the project"

   Copy

   [main d924dab] Add first note and describe the project
    2 files changed, 5 insertions(+)
    create mode 100644 notes/day-1.md

10. Read the history, long form and short form.

    $ git log

    Copy

    commit d924dabc12f199d7a7f304af8ed8f7536f20acd9
    Author: You <you@example.com>
    Date:   Wed Sep 9 14:55:55 2026 +0200
    
        Add first note and describe the project
    
    commit 548a37c701003e3dd9fc02cf00260ff29ccb00bb
    Author: You <you@example.com>
    Date:   Wed Sep 9 14:55:55 2026 +0200
    
        Add README

    Newest first. Each commit shows its full hash, author, date and message. The compact form is the one you will use daily:

    $ git log --oneline

    Copy

    d924dab Add first note and describe the project
    548a37c Add README

    If the long output fills the screen and ends with a colon, you are inside a viewer: press q to leave it.

11. Edit the note and look at the exact change.

    $ printf '\nI learned git add and git commit.\n' >> notes/day-1.md
    $ git diff

    Copy

    diff --git a/notes/day-1.md b/notes/day-1.md
    index 10e90f7..8dea74e 100644
    --- a/notes/day-1.md
    +++ b/notes/day-1.md
    @@ -1,3 +1,5 @@
     # Day 1
     
     Today I created my first repository.
    +
    +I learned git add and git commit.

    Lines starting with + were added; - would mark removed lines. The lines without a sign are context, shown so you can see where the change sits.

12. Make the classic mistake on purpose. Try to commit without staging:

    $ git commit -m "Update day 1 note"

    Copy

    On branch main
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git restore <file>..." to discard changes in working directory)
    	modified:   notes/day-1.md
    
    no changes added to commit (use "git add" and/or "git commit -a")

    Nothing was committed. Git prints a status report and the key sentence: no changes added to commit. The edit is on disk but not in the staging area. This message will greet you many times; now you know it simply means "you forgot git add".

13. Stage, commit, and confirm you have three commits.

    $ git add notes/day-1.md
    $ git commit -m "Update day 1 note"

    Copy

    [main 839a695] Update day 1 note
     1 file changed, 2 insertions(+)

    $ git log --oneline

    Copy

    839a695 Update day 1 note
    d924dab Add first note and describe the project
    548a37c Add README

14. Look inside one commit, and at the hidden folder.

    $ git show --stat HEAD

    Copy

    commit 839a695a81179c2133edc6c8bbfd677bc00a2e99
    Author: You <you@example.com>
    Date:   Wed Sep 9 14:55:55 2026 +0200
    
        Update day 1 note
    
     notes/day-1.md | 2 ++
     1 file changed, 2 insertions(+)

    $ ls -a

    Copy

    .
    ..
    .git
    README.md
    notes

    HEAD means "the commit I am on", so git show --stat HEAD summarizes your latest commit. ls -a reveals the .git folder that holds all three commits. Never edit anything inside it by hand.

Expected result

• git log --oneline lists three commits, newest first: "Update day 1 note", "Add first note and describe the project", "Add README". Your hashes differ from the ones shown.
• git status says nothing to commit, working tree clean.
• The folder contains README.md, notes/day-1.md and a hidden .git folder.

Common mistakes

• fatal: not a git repository on git status: you are not inside git-practice. Run pwd, then cd ~/git-practice.
• git init printed hints about master. Your Git has no default branch configured. Run git branch -m main now; the lab's outputs assume main.
• Author identity unknown. git commit refuses with Please tell me who you are. Set your name and email as in First-time configuration, then commit again.
• The commit opened an editor because you typed git commit without -m. Type a message on the first line, save and close the editor (in Vim: press Esc, type :wq, press Enter). Or close it without saving to cancel, and retry with -m.
• A stray file such as .DS_Store appeared in git status after git add .. macOS creates it. Remove it from the staging area with git rm --cached .DS_Store and ignore it for good in .gitignore.

$ cd ~ && mkdir git-practice && cd git-practice
$ git init
$ printf '# My Git practice\n' > README.md
$ git add README.md
$ git commit -m "Add README"
$ mkdir notes
$ printf '# Day 1\n\nToday I created my first repository.\n' > notes/day-1.md
$ printf '\nThis repository is where I practice Git.\n' >> README.md
$ git add .
$ git commit -m "Add first note and describe the project"
$ printf '\nI learned git add and git commit.\n' >> notes/day-1.md
$ git add notes/day-1.md
$ git commit -m "Update day 1 note"
$ git log --oneline

839a695 Update day 1 note
d924dab Add first note and describe the project
548a37c Add README

What happened and why

You ran the basic cycle three times: edit → git status → git add → git commit. Each git add copied a change from the working tree into the staging area; each git commit turned the staging area into a permanent snapshot with a hash and a message, and moved the main branch label forward to it. git log walks that chain backwards from HEAD.

The deliberate mistake in step 12 showed the rule behind the whole design: Git commits only what you staged. It is an extra step compared with "save", and it is what lets you decide, every time, exactly what goes into history.

Next: Level 2 connects a repository like this one to GitLab or GitHub, so your commits leave your computer.