Git Basics — Complete Beginner's Step-by-Step Guide

Git is a version control system that tracks every change to your files, lets you revert mistakes, and enables multiple developers to collaborate without overwriting each other’s work — like a time machine for your code.

What You’ll Learn

By the end of this tutorial, you’ll initialize a local Git repository, make commits with meaningful messages, view project history, compare file changes, and configure .gitignore to keep sensitive or unnecessary files out of version control.

Why Git Matters

Version control isn’t optional — it’s the foundation of professional software development. Git is used by 90%+ of developers worldwide, from solo coders to teams at Google and Microsoft. At DodaTech, every product — including Doda Browser, DodaZIP, and Durga Antivirus Pro — relies on Git for source control, release management, and collaborative development.

Security note: Understanding Git Basics helps build more secure applications — a core principle at DodaTech, where tools like Durga Antivirus Pro and Doda Browser rely on solid implementation practices.

Git Learning Path

    flowchart LR
  A[Git Basics] --> B[Branching & Merging]
  B --> C[Remote Repositories]
  C --> D[Undoing Changes]
  D --> E[Advanced Git]
  E --> F[Git Reference]
  style A fill:#3b82f6,stroke:#fff,color:#fff
  

How Git Works — The Three States

Think of Git as three rooms in a house:

1. Working Directory — your desk, where you edit files
2. Staging Area (Index) — a checklist, where you pick which changes to save
3. Repository (.git folder) — a filing cabinet, where snapshots are stored permanently

You edit on your desk (Working Directory), check off items (git add to Stage), then file them away (git commit to Repository).

    flowchart LR
  A[Working Directory<br/>your desk] -->|git add| B[Staging Area<br/>checklist]
  B -->|git commit| C[Local Repository<br/>filing cabinet]
  C -->|git push| D[Remote Repository<br/>GitHub / GitLab]
  D -->|git pull| A
  

Why three states? Because you don’t always want to save everything at once. Maybe you edited three files but only two are ready. The staging area lets you pick and choose — like putting only certain items into a photo album.

Installing Git

Let’s get Git on your machine. Choose the command for your operating system:

# Linux (Debian/Ubuntu) — most common for servers
sudo apt update && sudo apt install git -y

# Linux (Fedora/RHEL)
sudo dnf install git -y

# macOS (using Homebrew)
brew install git

# Windows — download from https://git-scm.com/downloads

# Verify it worked
git --version
# Expected output: git version 2.43.0 (or newer)

What just happened? We installed Git globally so it’s available from any terminal. The -y flag automatically answers “yes” to installation prompts.

First-Time Setup — Your Identity

Git stamps every commit with your name and email. Think of it like signing a check — without your signature, no one knows who wrote it.

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main

# View all settings
git config --list

Breaking it down:

• --global means “apply to every project on this computer” (until overridden)
• user.name and user.email are attached to every commit you make
• init.defaultBranch main sets the default branch name to main instead of master

Creating a Repository

A repository (repo) is a project folder that Git watches. You can start fresh or copy an existing one:

# Start fresh — creates a new empty repo
mkdir my-project
cd my-project
git init
# Initialized empty Git repository in my-project/.git/

# Copy existing — downloads a remote project
git clone https://github.com/user/repo.git
cd repo

Why two ways? git init is for starting something new — like buying a blank notebook. git clone is for copying someone else’s notebook — lectures, notes, everything.

The Basic Workflow — Your First Commit

The three-step dance: edit → stage → commit.

# 1. Check what's happening
git status

# 2. Stage files (add to the checklist)
git add index.html          # a single file
git add *.css               # all CSS files
git add .                   # everything in the folder

# 3. Commit (take the snapshot)
git commit -m "Add homepage with header and footer"

Line by line explanation:

• git status — Git tells you which files are new, changed, or staged. Run this often!
• git add index.html — tells Git “I want to include index.html in my next snapshot”
• git add . — stages everything. Convenient, but check git status first so you don’t accidentally stage secrets or build files
• git commit -m "..." — saves the snapshot permanently with a message describing the change

    flowchart LR
  A[Untracked] -->|git add| B[Staged]
  B -->|git commit| C[Committed]
  C -->|edit file| A
  

Why the message matters: Six months from now, git log will show your messages. “Fix stuff” tells you nothing. “Fix login form validation error” tells you exactly what happened.

Viewing History

Your commits form a timeline. Here’s how to read it:

git log                    # full history — author, date, message
git log --oneline          # compact — one line per commit
git log --graph            # shows branch structure visually
git log -p                 # shows the actual changes (diff) in each commit
git log --author="Alice"   # only Alice's commits
git log --since="2024-01-01"  # commits this year only

Sample output:

a1b2c3d (HEAD -> main) Add homepage with header and footer
d4e5f6g Initial commit

• a1b2c3d is the commit hash — a unique ID for this snapshot
• (HEAD -> main) means “the current position is main, and this is the latest commit”
• The message tells you what changed

Comparing Changes

Before committing, you’ll want to see exactly what changed:

git diff                   # unstaged changes (desk vs checklist)
git diff --staged          # staged changes (checklist vs last snapshot)
git diff a1b2c3d d4e5f6g   # between any two snapshots

Analogy: git diff is like holding up two photos side by side and circling the differences. It’s your safety net before committing.

.gitignore — Keeping Secrets Out

Some files should never be in Git: passwords, dependencies, build outputs. .gitignore tells Git to ignore them.

echo "node_modules/" >> .gitignore
echo ".env" >> .gitignore
echo "*.log" >> .gitignore
git add .gitignore
git commit -m "Add gitignore to exclude node_modules and secrets"

Common .gitignore patterns:

Common Mistakes

1. Committing without configuring user name and email

Git stamps commits with a generic system name (like “root” or your machine name). Always run git config --global user.name and user.email first. Otherwise your commits look unprofessional and don’t link to your account.

2. Staging sensitive files before adding .gitignore

You commit .env with your database password. Even if you delete it later, it’s forever in the history. Always create .gitignore before your first git add ..

3. Running git add . without checking git status

You might stage 500MB of node_modules, build artifacts, or your .env file. Run git status first. It takes two seconds and prevents disasters.

4. Writing vague commit messages

git commit -m "fix stuff"        # BAD — what stuff?
git commit -m "Fix login form validation error"  # GOOD

Good commit messages: present tense, imperative mood, ≤50 characters for the summary line. Think of it as a newspaper headline for your change.

5. Confusing git init with git clone

git init creates a new empty repo. git clone copies an existing one. Use init to start fresh; use clone to copy from GitHub. The wrong choice gives you either an empty folder or a duplicate.

6. Forgetting git add before git commit

You edit a file, type git commit -m "message", and Git says “nothing to commit.” You haven’t staged anything! Always git add first.

Practice Questions

1. What command do you run to start tracking a new project with Git?

Answer: git init in the project directory.

2. What is the difference between git add and git commit?

Answer: git add stages files (adds them to the checklist). git commit takes the snapshot and saves it permanently in the repository.

3. How do you see what changes you’ve made but haven’t staged yet?

Answer: git diff shows unstaged changes (working directory vs staging area).

4. What are three file types you should add to .gitignore and why?

Answer: .env (secrets), node_modules/ (dependencies), *.log (logs). They’re not part of your source code and can contain sensitive or machine-generated data.

Challenge

Create a new Git repo, add a Python script that prints “Hello, World!”, commit it, then modify it to print your name. Use git diff to see the change before committing the second version.

FAQ

Try It Yourself

Create a simple project page and track it with Git:

# 1. Create project
mkdir my-portfolio
cd my-portfolio
git init

# 2. Add files
echo "<h1>My Portfolio</h1>" > index.html
echo "node_modules/" > .gitignore
echo ".env" >> .gitignore

# 3. Configure user (if not done globally)
git config user.name "Your Name"
git config user.email "you@example.com"

# 4. Stage and commit
git add .
git commit -m "Initial commit: add index page and gitignore"

# 5. Verify
git status
git log --oneline

You now have a version-controlled project. Every change from here can be committed, reverted, or branched.

What’s Next

Now that you’ve mastered Git basics, advance to branching and collaboration:

Related topics to explore:

• Git Overview
• Linux Command Line
• DevOps Practices
• JavaScript Projects

What’s Next

Congratulations on completing this Git Basics tutorial! Here’s where to go from here:

• Practice daily — Consistency is more important than long study sessions
• Build a project — Apply what you learned by building something real
• Explore related topics — Check out other tutorials in the same category
• Join the community — Discuss with other learners and share your progress

Remember: every expert was once a beginner. Keep coding!