Skip to content

Version Control for Beginners — Git Basics Explained Step by Step

DodaTech Updated 2026-06-22 7 min read

In this tutorial, you'll learn about Version Control for Beginners. We cover key concepts, practical examples, and best practices.

Learn Git version control from scratch: repositories, commits, branches, merges, and remote hosting with step-by-step commands and real-world examples for beginners.

What You'll Learn

You will learn what version control is, why every developer uses Git, and how to create repositories, make commits, work with branches, and collaborate with others using remote hosting platforms.

Why It Matters

Version control is the safety net for every software project. It tracks every change, lets you undo mistakes, enables multiple people to work on the same code simultaneously, and provides a complete history of your project. Without version control, you risk losing work, overwriting changes, and having no way to recover from errors.

Real-World Use

The Doda Browser development team has over 50,000 commits in their Git repository. When a bug was introduced in version 4.2, the team used git bisect to pinpoint the exact commit that caused the regression, rolled it back, and shipped a fix within hours. Without version control, finding that bug would have taken days.

Your Learning Path

flowchart LR
  A[File Systems & Paths] --> B[Version Control Basics]
  B --> C[How to Read Docs]
  C --> D[Terminal Basics]
  D --> E[First Programming Language]
  B --> F{You Are Here}
  style F fill:#f90,color:#fff
â„šī¸ Info

Prerequisites: Basic command-line familiarity (navigating directories, listing files). If you have not used the terminal yet, review the Terminal for Beginners tutorial first.

What Is Version Control?

Version control is a system that records changes to files over time so you can recall specific versions later. Think of it like an infinite undo button combined with a time machine for your project.

Local vs Centralized vs Distributed

System Type Examples How It Works
Local RCS, SCCS Keeps patch sets on your local disk
Centralized SVN, Perforce One central server stores all versions
Distributed Git, Mercurial Every clone has the full history

Git is a distributed version control system. Every developer has a complete copy of the entire repository, including full history. This means you can work offline, commit locally, and sync when ready.

Installing and Configuring Git

# Check if Git is installed
git --version

# Configure your identity (do this once)
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

# Set your default branch name
git config --global init.defaultBranch main

# Verify configuration
git config --list

Expected output: The version number appears (e.g., git version 2.40.0), then your name and email are stored globally. All future commits will use this identity.

Creating Your First Repository

# Create a new project directory
mkdir my-first-project
cd my-first-project

# Initialize a Git repository
git init

# Check the status
git status

Expected output: git init prints Initialized empty Git repository in /home/user/my-first-project/.git/. The git status command shows On branch main and No commits yet.

The .git folder created by git init is the repository database. Never delete or edit it manually.

Making Your First Commit

# Create a file
echo "# My First Project" > README.md
echo "print('Hello, Git!')" > hello.py

# Stage files
git add README.md hello.py

# Commit with a message
git commit -m "Initial commit: add README and hello script"

Expected output:

[main (root-commit) a1b2c3d] Initial commit: add README and hello script
 2 files changed, 2 insertions(+)
 create mode 100644 README.md
 create mode 100644 hello.py

The commit hash a1b2c3d uniquely identifies this snapshot. Every commit gets a unique SHA-1 hash that you can use to reference it later.

Understanding the Three States

Git has three main states that your files can be in:

State Description Location
Modified File changed but not staged Working directory
Staged Marked for inclusion in next commit Staging area (index)
Committed Safely stored in repository .git directory
flowchart LR
  A[Working Directory] -->|git add| B[Staging Area]
  B -->|git commit| C[Local Repository]
  C -->|git push| D[Remote Repository]
  D -->|git pull| A
  style A fill:#4a9,color:#fff
  style B fill:#49a,color:#fff
  style C fill:#47a,color:#fff
  style D fill:#45a,color:#fff

Branching and Merging

Branches let you work on features, fixes, or experiments in isolation without affecting the main codebase.

# List branches
git branch

# Create a new branch
git branch feature-login

# Switch to the new branch
git checkout feature-login

# Or create and switch in one command
git checkout -b feature-login

# Make changes on the branch
echo "def login(): pass" > auth.py
git add auth.py
git commit -m "Add login function skeleton"

Expected behavior: The new branch starts as an exact copy of main. Any commits made on feature-login do not affect main. You can switch back to main with git checkout main.

Merging a Branch

# Switch back to main
git checkout main

# Merge the feature branch
git merge feature-login

# Delete the branch (optional)
git branch -d feature-login

Expected output: git merge shows a fast-forward merge if no divergent changes exist, or creates a merge commit if both branches have diverged.

Working with Remote Repositories

Remote repositories are hosted on platforms like GitHub, GitLab, or Bitbucket. They enable collaboration and backup.

# Add a remote
git remote add origin https://github.com/username/my-first-project.git

# Push local commits to remote
git push -u origin main

# Clone an existing repository
git clone https://github.com/username/existing-project.git

# Pull latest changes
git pull origin main

Expected behavior: After git push, your commits appear on the remote platform. git pull fetches remote changes and merges them into your local branch.

Common Git Mistakes and Errors

1. Committing to the Wrong Branch

Making commits on main when you intended to create a feature branch. Fix: git checkout -b feature-name before starting work, or use git cherry-pick to move commits.

2. Forgetting to Pull Before Pushing

Your local branch has diverged from the remote. Fix: git pull --rebase origin main to rebase your changes on top of the latest remote commits, then push again.

3. Committing Large Files

Git stores every version of every file. Committing large binaries (videos, compiled binaries) bloats the repository. Fix: Use .gitignore to exclude build artifacts, or use Git LFS for large files.

4. Writing Vague Commit Messages

A commit message like fix stuff provides no context. Fix: Write descriptive messages following the conventional format: type: brief description. Example: feat: add user authentication endpoint.

5. Using git reset --hard Without Thinking

The --hard flag discards all uncommitted changes permanently. Fix: Use git stash to save changes temporarily, or use git checkout -- <file> for individual files.

6. Merging Instead of Rebasing on Shared Branches

Merge commits on shared branches create unnecessary history complexity. Fix: Use git pull --rebase and rebase feature branches before merging to keep history linear.

7. Storing Secrets in Repositories

Accidentally committing API keys, passwords, or tokens. Fix: Add sensitive files to .gitignore. If already committed, use git filter-branch or BFG Repo-Cleaner to remove them, then rotate the secrets.

Practice Questions

1. What is the difference between git add and git commit? git add moves changes from the working directory to the staging area. git commit saves the staged snapshot to the repository history with a message.

2. What does git pull do? It fetches changes from the remote repository and merges them into the current local branch. It is equivalent to git fetch followed by git merge.

3. How do you create a new branch and switch to it in one command? Run git checkout -b branch-name. The -b flag creates the branch and checks it out immediately.

4. Why should you avoid committing large binary files to a Git repository? Git stores the full content of every version. Large binaries make the repository grow quickly, slow down clones and fetches, and increase storage costs.

5. Challenge: Create a new repository, make three commits on main, create a feature branch, make two more commits, merge the feature branch back to main, and push everything to a remote. Use descriptive commit messages throughout.

Mini Project: Create a Personal Diary Repository

Initialize a Git repository for a personal coding diary. Create files for each week, make commits with meaningful messages, create a branch for experimental entries, and set up a .gitignore to exclude temporary editor files. Practice branching, merging, and viewing the log with git log --oneline --graph.

# Create and initialize
mkdir coding-diary
cd coding-diary
git init
echo ".DS_Store\n*.swp\n*.swo" > .gitignore
git add .gitignore
git commit -m "chore: add gitignore for editor files"

# Create week entries
for week in 1 2 3; do
  echo "# Week $week\n\nLearning: Git basics" > "week-$week.md"
  git add "week-$week.md"
  git commit -m "docs: add week $week diary entry"
done

# View history
git log --oneline --graph --all

Expected output: A linear history of four commits (gitignore plus three week entries). The --graph flag shows branch structure visually.

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro.

Built by the developers of DodaTech

Doda Browser, DodaZIP & Durga Antivirus Pro