Your First Git Repository: init, add, commit and log

Git and GitHub Essentials: Version Control for Beginners · Git Basics · 6 min read · Updated

Three areas of Git

  1. You edit files in your working folder, as you always do.
  2. git add moves the changes you choose into the staging area, a waiting room for the next snapshot.
  3. git commit stores the staged changes as a permanent snapshot, with a message, in the repository.
  4. git log shows the history of snapshots, newest first.

A repository (repo) is a project folder that Git is tracking. In this lesson you create one, make your first commits and learn the three places where your changes live. These three places are the key to understanding Git, so we go slowly. Everything below is a real session recorded from Git, and you can type the same commands in an empty folder.

The three areas

  1. Working folder: the files you see and edit, as normal.
  2. Staging area (the index): a waiting room. You choose which changes go into the next snapshot with git add.
  3. Repository (history): the saved snapshots, called commits. git commit takes what is in the staging area and stores it permanently.

Why the middle step? It lets you save a neat, focused commit even if you changed many things. You might fix a typo and add a feature in the same hour, and then commit them separately, so the history is easy to read.

Create a repository and the first commit

Make a folder called recipes, go into it, and follow along. We use git status very often, because it tells you what is happening and often what to do next.

$ git init
Initialized empty Git repository in /home/asha/recipes/.git/
$ git status
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)
$ git add README.md
$ git status -s
A  README.md
$ git commit -m "Add README"
[main (root-commit) 8205bb9] Add README
 1 file changed, 2 insertions(+)
 create mode 100644 README.md
$ git log --oneline
8205bb9 Add README
$ git diff
diff --git a/README.md b/README.md
index 7004fd6..6e63d1b 100644
--- a/README.md
+++ b/README.md
@@ -1,2 +1,4 @@
 # Recipes
 My favourite recipes.
+
+- Masala chai
$ git status -s
 M README.md
$ git add -A
$ git commit -m "Add masala chai to the list"
[main d50d959] Add masala chai to the list
 1 file changed, 2 insertions(+)
$ git status -s
?? .gitignore
$ git add .gitignore && git commit -m "Ignore log files and private notes"
[main e50e5b8] Ignore log files and private notes
 1 file changed, 2 insertions(+)
 create mode 100644 .gitignore
$ git log --oneline
e50e5b8 Ignore log files and private notes
d50d959 Add masala chai to the list
8205bb9 Add README

What happened, step by step

  • git init created the hidden .git folder. The folder is now a repository on the branch main, with no commits yet.
  • After we created README.md, git status listed it as untracked: Git sees the file but is not tracking it.
  • git add README.md moved it into the staging area. git status -s (short form) shows A for added.
  • git commit -m "Add README" saved the snapshot with a message. Git printed a short commit code (the hash, such as 8205bb9), which is different on your computer.
  • git log --oneline shows the history with one line for each commit, newest first.
  • After we edited the file, git diff showed exactly what changed: lines starting with + were added. The short status shows M, which means modified but not staged.
  • git add -A stages every change, and the second commit stored it. Use git add . for the same effect inside the current folder.

Ignoring files with .gitignore

Some files should not be in the history: temporary files, logs, passwords and large folders created by tools. List them in a file called .gitignore, one pattern per line. In the session, we ignored all *.log files and a folder called notes_private/. After that, git status -s stopped showing debug.log. Only .gitignore itself appeared as new, and we committed it, so the rule is shared with everyone who clones the project.

  • *.log matches every file that ends with .log.
  • node_modules/ ignores a whole folder (a trailing slash means folder).
  • .env is a common line for files with secrets. Lesson 8 explains why this matters.
  • .gitignore only affects files that are not yet tracked. If you already committed a file, ignoring it later does not remove it from the history.
  • Many examples exist for each language and tool. Search for a ready-made .gitignore for the tools you use.

Reading git status

git status is your compass. It tells you the branch, which files are untracked, which are changed and which are staged, and it usually suggests the next command. When you are unsure what state your project is in, run it. It changes nothing, and it is always safe.

Habits that make Git easy

  • Commit small and often. Each commit should be one logical change that you can describe in a short sentence.
  • Run `git status` before and after each command until it feels natural.
  • Check `git diff` before you add, so you know what you are saving.
  • Do not commit generated files or secrets.

Your task

  1. Make a folder recipes, run git init, and create README.md with two lines.
  2. Run git status, git add README.md, and git commit -m "Add README".
  3. Edit the README, run git diff to see the change, then add and commit again.
  4. Create a .gitignore that ignores *.log, create a file debug.log, and check that git status -s does not show it.
  5. Run git log --oneline and count your commits.

How to check it worked

  • git log --oneline shows at least three commits, newest first.
  • git status says nothing to commit, working tree clean after your last commit.
  • debug.log never shows up in git status.

Frequently asked questions

What is the staging area for?

It lets you choose exactly which changes go into the next commit, so each commit can be small and focused even if you changed many things.

Why is my file not showing up in git status after I added it to .gitignore?

That is the purpose of .gitignore. The file is hidden from Git. If it still appears, it was already tracked before, and you must remove it from tracking with git rm --cached.