LFCA 86 🐧 Git Basics — init, add, commit - KandZ

Version control is the foundation of collaborative software development. Git is the version control system that dominates the industry, and it is one of the core tools the LFCA exam expects you to know under DevOps Fundamentals, which carries 12–16% of the total weight. The study plan lists “Git” as a core DevOps tool alongside CI/CD and deployment environments.

Three commands form the foundation of every Git workflow: git init, git add, and git commit. They create the repository, stage the changes, and record the snapshot. Every other Git command builds on these three. This chapter covers the three commands, the three states of a file in Git, and the workflow that connects them.

Key point: A Git repository has three areas: the working directory, the staging area, and the repository. Files move through these areas in a defined order. A change in the working directory is not tracked until it is staged with git add. A staged change is not recorded until it is committed with git commit. The three commands — init, add, commit — map directly to these three areas.

Why the three commands matter

Every Git operation is built on the foundation that these three commands establish. Understanding what each command does and which area it affects is the difference between using Git as a tool and fighting it as an obstacle.

The init problem. A directory is not a Git repository until git init is run. The command creates a hidden .git directory that contains the repository’s metadata: the configuration, the object database, the refs, and the index. Without this directory, Git commands do not work. The directory is the marker that distinguishes a Git repository from an ordinary directory .

The add problem. A file in the working directory is not tracked by Git. Git sees the file only after it is staged with git add. The staging area is the intermediate zone between the working directory and the repository. It is the place where the developer chooses what goes into the next commit. A developer can stage some changes and leave others unstaged, creating a commit that contains only the changes that belong together .

The commit problem. A staged change is not recorded in the repository’s history until git commit is run. The commit creates a new snapshot of the project. The snapshot is identified by a SHA-1 hash. The commit records the author, the timestamp, the commit message, and a pointer to the previous commit. The history is the chain of commits .

The trade-off. The three-area model adds a step between editing and recording. A developer could edit a file and have it tracked immediately. Git requires the explicit git add step. The extra step is what makes the staging area useful. The developer can stage part of a change, review it, and commit it separately from other changes. The flexibility is the point.

a. git init — Creating a Repository

The git init command creates a new Git repository. It is the first command run in any project that is not already under version control.

git init

The command creates a hidden .git directory in the current directory. The directory contains:

config is the repository’s configuration. It stores the repository format version, the file mode, the ignore case setting, and any remote configuration.

HEAD is a file that points to the current branch. It contains a reference like ref: refs/heads/main.

objects/ is the object database. Every commit, tree, and blob is stored here, identified by its SHA-1 hash.

refs/ is the directory for branch references. Each branch is a file in refs/heads/ that contains the SHA-1 hash of the commit the branch points to.

index is the staging area. It is a binary file that records the state of the staged files.

The repository is initialized with no commits and no tracked files. The git status command shows that there is nothing to commit.

The git init command can also initialize a bare repository with the --bare flag. A bare repository has no working directory. It is used as a remote on a server. The default repository created by git init has a working directory and is used for local development.

The initial branch name can be specified with the -b flag:

git init -b main

Without the flag, Git uses the default branch name, which is master in older versions and main in newer versions. The default can be configured globally with git config --global init.defaultBranch main.

b. git add — Staging Changes

The git add command stages changes from the working directory to the staging area. The staging area is the index. The index is the list of changes that will be included in the next commit.

To stage a single file:

git add README.md

To stage multiple files:

git add README.md src/index.ts src/app.ts

To stage all changes in the current directory:

git add .

To stage all changes in the repository:

git add -A

The difference between git add . and git add -A is subtle. The . stages all changes in the current directory and its subdirectories. The -A stages all changes in the entire repository, including deletions. The . also stages deletions in the current directory, but does not reach files outside the current directory.

The git add command accepts the -p flag, which stages changes interactively. The developer can choose which hunks of a file to stage and which to leave unstaged. This is useful when a file contains multiple changes that belong in different commits.

git add -p

The interactive mode prompts for each hunk. The developer can stage it (y), skip it (n), split it into smaller hunks (s), or edit it (e).

The git add command also accepts the -u flag, which stages only the changes to files that are already tracked. New untracked files are not staged. This is useful when a new file is not ready to be committed.

git add -u

The staging area can be inspected with git status. The output shows the staged changes in the “Changes to be committed” section and the unstaged changes in the “Changes not staged for commit” section.

c. git commit — Recording the Snapshot

The git commit command records the staged changes as a new commit in the repository. The commit is a snapshot of the project at the moment of the commit.

The simplest form opens the default editor for the commit message:

git commit

The -m flag provides the message inline:

git commit -m "Add user authentication"

The -a flag stages all tracked files that have been modified and commits them in a single step. New untracked files are not included.

git commit -am "Fix login validation"

The -a flag is a shortcut for git add -u followed by git commit. It does not include new files. The developer must still git add a new file before committing it.

The --amend flag modifies the most recent commit. It is used to fix a commit message, add a forgotten file, or remove a file that should not have been committed.

git commit --amend

The --amend flag replaces the last commit with a new commit. The new commit has a new hash. The old commit is no longer reachable from the branch. It is still in the object database and can be recovered with git reflog, but it is not part of the branch’s history.

The commit message should describe the change. A good commit message has a short subject line (under 50 characters) and an optional body that explains the what and the why. The subject line is what appears in the git log output. The body is the detail.

Add user authentication

Implement JWT-based authentication for the API.
The tokens are stored in HTTP-only cookies.
Add a middleware to validate the tokens on protected routes.

The git log command shows the commit history. The git log --oneline shows a compact view. The git log --graph shows the branch structure.

Complete Example Session

This session creates a repository, stages files, commits, and inspects the result.

# ============================================
# PART 1: INITIALIZE A REPOSITORY
# ============================================

mkdir my-project
cd my-project
git init

# Output:
# Initialized empty Git repository in /path/to/my-project/.git/

# The .git directory is created.
# The repository has no commits and no tracked files.

# ============================================
# PART 2: CHECK THE STATUS
# ============================================

git status

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

# ============================================
# PART 3: CREATE A FILE
# ============================================

echo "# My Project" > README.md

# The file is in the working directory.
# Git sees it as untracked.

git status

# Output:
# 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

# ============================================
# PART 4: STAGE THE FILE
# ============================================

git add README.md

# The file is now staged.
# The staging area contains the change.

git status

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

# ============================================
# PART 5: COMMIT THE CHANGE
# ============================================

git commit -m "Add README"

# Output:
# [main (root-commit) a1b2c3d] Add README
#  1 file changed, 1 insertion(+)
#  create mode 100644 README.md

# The commit is recorded.
# The commit hash is a1b2c3d.

# ============================================
# PART 6: VIEW THE LOG
# ============================================

git log

# Output:
# commit a1b2c3d4e5f6...
# Author: Alice <alice@example.com>
# Date:   Thu Oct 1 12:00:00 2026 +0000
#
#     Add README

# ============================================
# PART 7: MODIFY THE FILE
# ============================================

echo "## Installation" >> README.md

# The file is modified.
# Git sees the modification.

git status

# Output:
# 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

# ============================================
# PART 8: STAGE AND COMMIT THE MODIFICATION
# ============================================

git add README.md
git commit -m "Add installation section"

# Output:
# [main b2c3d4e] Add installation section
#  1 file changed, 1 insertion(+)

# ============================================
# PART 9: STAGE ALL CHANGES
# ============================================

echo "## Usage" >> README.md
echo "npm install" > package.json

git add .

git status

# Output:
# On branch main
# Changes to be committed:
#         modified:   README.md
#         new file:   package.json

git commit -m "Add usage section and package.json"

# ============================================
# PART 10: VIEW THE FULL HISTORY
# ============================================

git log --oneline

# Output:
# c3d4e5f Add usage section and package.json
# b2c3d4e Add installation section
# a1b2c3d Add README

# The history is a chain of commits.
# Each commit points to the previous commit.

The ten parts cover initializing a repository, checking the status, creating a file, staging the file, committing the change, viewing the log, modifying the file, staging and committing the modification, staging all changes, and viewing the full history.

Quick Reference

The Three Commands

Command	Purpose
`git init`	Create a repository
`git add`	Stage changes
`git commit`	Record the snapshot

The Three Areas

Area	Description
Working directory	The files on disk
Staging area (index)	The changes ready to commit
Repository	The commit history

The git init Options

Option	Purpose
`--bare`	Create a bare repository
`-b main`	Set the initial branch name
`--initial-branch=main`	Set the initial branch name

The git add Options

Option	Purpose
`git add file`	Stage a specific file
`git add .`	Stage all changes in the current directory
`git add -A`	Stage all changes in the repository
`git add -u`	Stage changes to tracked files only
`git add -p`	Stage changes interactively

The git commit Options

Option	Purpose
`git commit`	Commit with editor
`git commit -m "msg"`	Commit with inline message
`git commit -am "msg"`	Stage tracked files and commit
`git commit --amend`	Modify the last commit

The git status Sections

Section	Meaning
Changes to be committed	Staged changes
Changes not staged for commit	Modified but unstaged
Untracked files	Not yet tracked

Best Practices

✅ Do This:

# Initialize with the main branch name
git init -b main                                                # ✅

# Check the status before committing
git status                                                       # ✅

# Stage specific files
git add README.md src/index.ts                                  # ✅

# Write a meaningful commit message
git commit -m "Add user authentication with JWT"                # ✅

# Use git add -p to stage partial changes
git add -p                                                       # ✅

❌ Don’t Do This:

# Don't commit without checking the status
git commit -am "stuff"  # may include unwanted files            # ❌

# Don't write vague commit messages
git commit -m "fix"                                              # ❌

# Don't commit secrets
git add .env                                                     # ❌

# Don't use --amend on a commit that has been pushed
git commit --amend  # rewrites history                           # ❌

# Don't commit large binary files
git add video.mp4                                                # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
File not tracked	Not staged	`git add file`
Unwanted file committed	`git add .` includes everything	Use `.gitignore`
Forgot to stage a file	Staged before the change	`git add file` again
Commit message wrong	Typo	`git commit --amend`
Committed to wrong branch	No branch check	`git checkout -b` first

Real-World Examples

1. Initialize

git init -b main

2. Stage a File

git add README.md

3. Stage All Changes

git add .

4. Commit with Message

git commit -m "Add README"

5. Stage and Commit Tracked

git commit -am "Fix bug"

6. Amend the Last Commit

git commit --amend -m "Better message"

7. Check Status

git status

8. View History

git log --oneline

9. Stage Interactively

git add -p

10. Check What Is Staged

git diff --staged

Visual

The Three Areas

┌──────────────────────────────────────────────┐
│  WORKING DIRECTORY                           │
│    The files on disk                         │
│       │                                      │
│       │  git add                             │
│       ▼                                      │
│  STAGING AREA (INDEX)                        │
│    The changes ready to commit               │
│       │                                      │
│       │  git commit                          │
│       ▼                                      │
│  REPOSITORY                                  │
│    The commit history                        │
│                                              │
│  Files move through three areas.             │
│  Each command affects one area.              │
│                                              │
└──────────────────────────────────────────────┘

The File States

┌──────────────────────────────────────────────┐
│  FILE STATES                                 │
│                                              │
│  Untracked:                                  │
│    └─ Not in Git yet                         │
│    └─ git add → Staged                       │
│                                              │
│  Modified:                                   │
│    └─ Changed since last commit              │
│    └─ git add → Staged                       │
│                                              │
│  Staged:                                     │
│    └─ Ready for the next commit              │
│    └─ git commit → Committed                 │
│                                              │
│  Committed:                                  │
│    └─ Recorded in the repository             │
│                                              │
└──────────────────────────────────────────────┘

The Commit Chain

┌──────────────────────────────────────────────┐
│  COMMIT CHAIN                                │
│                                              │
│  A ──> B ──> C ──> D                         │
│                                              │
│  A: Add README                               │
│  B: Add installation section                 │
│  C: Add usage section                        │
│  D: Fix typo                                 │
│                                              │
│  Each commit points to the previous one.     │
│  HEAD points to the latest commit.           │
│                                              │
└──────────────────────────────────────────────┘

The git status Output

┌──────────────────────────────────────────────┐
│  git status                                  │
│                                              │
│  Changes to be committed:                    │
│    └─ Staged changes                         │
│                                              │
│  Changes not staged for commit:              │
│    └─ Modified but not staged                │
│                                              │
│  Untracked files:                            │
│    └─ Not tracked by Git                     │
│                                              │
│  The status shows the state of each area.    │
│                                              │
└──────────────────────────────────────────────┘

Summary

Item	Value
git init	Create a repository
git add	Stage changes
git commit	Record the snapshot
Working directory	Files on disk
Staging area	Changes ready to commit
Repository	Commit history
Commit hash	SHA-1 identifier
Commit message	Description of the change
git status	Show the state of each area
git log	Show the commit history
LFCA weight	DevOps Fundamentals, 12–16%

Key takeaways:

git init creates a repository. The command creates the hidden .git directory that contains the repository’s metadata, object database, refs, and index. Without this directory, Git commands do not work .
git add stages changes. The staging area is the intermediate zone between the working directory and the repository. The developer chooses what goes into the next commit by staging the changes that belong together .
git commit records the snapshot. The commit creates a new snapshot of the project, identified by a SHA-1 hash. The commit records the author, the timestamp, the commit message, and a pointer to the previous commit .
The three areas are the working directory, the staging area, and the repository. Files move through these areas in a defined order. The working directory is the files on disk. The staging area is the changes ready to commit. The repository is the commit history .
A file has four states: untracked, modified, staged, and committed. The git status command shows the state of each file. The state determines what the next git add or git commit will include .
The commit message should describe the change. A good message has a short subject line (under 50 characters) and an optional body that explains the what and the why. The message is the record of why the change was made .
The --amend flag modifies the last commit. It is used to fix a message, add a forgotten file, or remove a file. It should not be used on a commit that has been pushed to a shared repository, because it rewrites the history.

Remember: git init creates the repository. git add stages the changes. git commit records the snapshot. The three commands form the foundation of every Git workflow. The staging area is the intermediate zone that lets the developer choose what goes into each commit. The commit is the snapshot that becomes part of the project’s history. The three commands are the first three commands every Git user learns.

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!