[Git Series Part 3] Create a Repository and Make Your First Commit - init, add, commit

한국어 버전

Create a Repository and Make the First Commit

In this part, you will practice the basic Git cycle on a real folder: initialize a repository, create files, stage them, and save them as commits.


What We Will Do

  • Initialize a Git repository
  • Watch how a file moves from untracked to staged to committed
  • Make the first commit and inspect the history
  • Make one more commit so the workflow becomes familiar

Requirements

  • A terminal with Git installed
  • Git configured with your name and email from Part 2

If you already finished the previous post in this series, you are ready to follow these commands as-is.

The Three File States in This Post

Before running commands, it helps to know the three states you will see in git status.

[New file] -> untracked
     |
     | git add
     v
[Staged] -> changes to be committed
     |
     | git commit
     v
[Committed] -> saved in Git history
  • untracked: Git sees the file, but is not tracking it yet.
  • staged: The file is in the staging area, ready for the next commit.
  • committed: The staged snapshot is now part of your repository history.

Lab 1: Create a Project Folder

Make the folder for practice

Create a project folder zsh · ~/workspace
Ready. Press Replay to run the scripted session.

The folder is now ready for Git.


Lab 2: Initialize the Repository

Run git init

Initialize Git zsh · ~/workspace
Ready. Press Replay to run the scripted session.

What is the .git folder? It is a hidden folder where Git stores your repository data and history. Do not delete it unless you intentionally want to remove Git tracking from the folder.

Check status

Check the initial status zsh · ~/workspace
Ready. Press Replay to run the scripted session.

Modern Git often shows main here, but some systems still use master. Either branch name is fine for this exercise.

At this point, Git knows the folder is a repository, but there are no tracked files and no commits yet.


Lab 3: Create the First File

Create a README as the first tracked file

Create README and verify zsh · ~/workspace
Ready. Press Replay to run the scripted session.

README.md appears under Untracked files, which means Git sees it but it is not part of the next commit yet.


Lab 4: Stage Changes

Add the file to the staging area

Why stage first? Git lets you choose exactly which changes belong in the next commit. The staging area is the waiting room between editing a file and saving a snapshot.

Stage the file zsh · ~/workspace
Ready. Press Replay to run the scripted session.

Changes to be committed means the file is staged and ready for the next commit.

If you want to stage every new or changed file in the current folder, you will often see git add . in real projects. In this post, we use git add README.md so you can see exactly what is happening.


Lab 5: Commit

Make the first commit from the staged file

git commit -m "message" creates a commit, and -m means you are writing the commit message directly in the command.

First commit zsh · ~/workspace
Ready. Press Replay to run the scripted session.

What is a commit? It is a snapshot of the staged changes at that moment, along with metadata such as the author, time, and parent commit.

(root-commit) means this is the first commit in the repository, so it has no parent commit before it.

For practice, the message is simple. In real work, prefer short action-style messages such as Add README.


Lab 6: View History

Show the log and read each part

View commit history zsh · ~/workspace
Ready. Press Replay to run the scripted session.

Read the full log like this:

  • commit abc1234def5678...: the commit hash, which uniquely identifies this commit.
  • Author: the name and email from your Git configuration.
  • Date: when the commit was created.
  • First commit: add README: the commit message.

git log --oneline shows a shorter version that is easier to scan. Git often shows an abbreviated hash there instead of the full hash.


Lab 7: Make a Second Commit

Add another file and repeat the workflow

One commit is enough to learn the mechanics, but a second commit helps you see that Git history grows one snapshot at a time, with the newest commit shown first in the log.

Second commit zsh · ~/workspace
Ready. Press Replay to run the scripted session.

You have now completed the full cycle twice:

  1. create or change a file
  2. stage it with git add
  3. save it with git commit
  4. review it with git log

Key Commands Recap

Command Description
git init Initialize a repository
git status Check state
git add filename Stage a file
git add . Stage all changes in the current directory
git commit -m "message" Create a commit
git log Show full history
git log --oneline Short history view

Troubleshooting

"fatal: not a git repository"

Cause: You have not initialized a repo.

Fix:

git init
# or move into the folder that already has .git
cd path/to/project

If your terminal output wraps differently from the examples in this post, that is normal. Terminal width changes how git status and git log look.

Wrong commit message

Fix:

git commit --amend -m "Better message"

Use --amend only for commits that have not been pushed to a shared remote yet.

Forgot to add a file before committing

Fix:

git add missing-file.txt
git commit --amend --no-edit

The same safety rule applies here: avoid amending commits that other people may already have pulled.


Practice Checklist

  • Ran git init
  • Checked status with git status after each main step
  • Staged files with git add
  • Committed with git commit
  • Viewed history with git log
  • Created two or more commits

Next in the Series

👉 Git Series Part 4: Connect GitHub - push, pull, clone

💬 댓글

이 글에 대한 의견을 남겨주세요