Git for Beginners: Basics and Essential Commands
Master version control fundamentals - Learn Git core concepts, essential commands, and developer workflows from scratch
BCA student and developer who loves learning in public. I build web and mobile projects, explore databases and backend systems, and document my journey through blogs. Currently focused on writing clean code and growing one commit at a time.
Ever deleted a chunk of code by mistake and wished you could just rewind time? Or maybe you’ve tried to work on a project with others, only to end up stepping on each other’s toes and overwriting changes. Honestly, that’s where Git comes in—it keeps your work safe and helps teams stay sane. If you write code, you need Git. No question.
Introduction
Git isn’t just another tool—it’s the backbone of modern development. At its core, Git tracks every change in your files and keeps everyone on the same page, whether you’re working alone or with a huge team. Linus Torvalds built it back in 2005 for Linux kernel development, and now, pretty much everyone uses it to manage code.
If you’re serious about building software today, you have to know Git. This guide gets you started and shows you how to use Git with confidence in your daily routine.
What You Need Before You Start
You should know your way around the terminal, at least the basics.
Have a code editor you like—maybe VS Code, Sublime Text, whatever works for you.
Make sure Git’s installed on your computer (grab it from the official website if you haven’t already).
What’s Git, and why bother with it?
What Makes Git Different?
Here’s what sets Git apart. Most version control systems track changes by saving the differences between files — you know, just the pieces that changed. Git doesn’t do that. Instead, every time you hit commit, Git snaps a photo of your whole project. It remembers exactly how everything looked right then and saves a reference to that full snapshot.
Why Developers Love Git
| Feature | Benefit |
| Distributed | Every developer has a full copy of the repository |
| Local Operations | Most operations work offline - no network latency |
| Data Integrity | SHA-1 checksums ensure nothing can be changed without Git knowing |
| Branching | Lightweight branches make experimentation easy |
| Speed | Operations are blazingly fast compared to centralized systems |
💡 Tip: Because Git is distributed, you can commit, branch, and view history without any network connection. You only need connectivity when sharing changes with others.
Core Concepts and Terminology
Let’s get the basics down before jumping into any commands:
Repository (Repo)
This is just a folder that Git keeps an eye on. It holds all your project files and, tucked away in a hidden .git directory, the full history of every change you’ve made.
my-project/
├── .git/ # Git's database (hidden)
├── src/
├── index.html
└── README.md
Commit
Think of a commit as a snapshot—a freeze-frame of your project at a certain moment.
Every commit has its own unique ID (that weird string of letters and numbers),
the name of whoever made it, a timestamp
A message explaining what changed
and a link to the commit that came just before it.
Branch
A branch is basically a movable label that points to a commit. Most projects start with a main branch, usually called main or master.
HEAD
HEAD is Git’s way of showing you where you’re standing right now. It points to the branch or commit you’re currently working on—like a big “you are here” marker on a map.
Remote
A remote is just a copy of your repo that lives somewhere else, like on GitHub, GitLab, or Bitbucket. By default, most people call it origin.
Git has three states you really need to know if you want to get the hang of it:
Understanding Git's three states is crucial for mastering Git:
Modified: You changed a file, but it’s not staged yet.
Staged: You’ve flagged that changed file, so it’s ready for your next commit.
Committed: Now it’s locked in, saved to your local Git database.
This leads to three main sections of a Git project:
| Section | Description | State |
| Working Directory | Files you see and edit | Modified |
| Staging Area (Index) | Preview of your next commit | Staged |
| Git Directory (.git) | Where Git stores metadata and history | Committed |
Here’s how the basic Git workflow goes:
Modify some changes to your files.
Pick the changes you want to keep and stage them.
Commit those staged changes. Git takes a snapshot and stores it for good.
Essential Git Commands
Configuration (One-time Setup)
Before using Git, configure your identity:
# Set your name
git config --global user.name "Your Name"
# Set your email
git config --global user.email "your.email@example.com"
# Verify configuration
git config --list
Creating Repositories
git init - Initialize a New Repository
Creates a new Git repository in the current directory:
# Navigate to your project folder
cd my-project
# Initialize Git
git init
# Output: Initialized empty Git repository in /path/to/my-project/.git/
git clone - Clone an Existing Repository
Creates a copy of a remote repository:
# Clone via HTTPS
git clone https://github.com/username/repository.git
# Clone via SSH
git clone git@github.com:username/repository.git
# Clone into a specific folder
git clone https://github.com/username/repository.git my-folder
Checking Status
git status - Check Repository Status
Shows the state of your working directory and staging area:
git status
# Output example:
# On branch main
# Changes to be committed:
# (use "git restore --staged <file>..." to unstage)
# new file: index.html
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# modified: style.css
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
# script.js
💡 Tip: Use
git status -sfor a shorter, cleaner output format.
Staging Changes
git add - Stage Changes
Adds files to the staging area:
# Stage a specific file
git add filename.txt
# Stage multiple files
git add file1.txt file2.txt
# Stage all changes in current directory
git add .
# Stage all changes in the entire repository
git add -A
# Interactively choose what to stage
git add -p
Committing Changes
git commit - Record Changes
Creates a snapshot of staged changes:
# Commit with a message
git commit -m "Add user authentication feature"
# Commit with a detailed message (opens editor)
git commit
# Stage all tracked files and commit in one step
git commit -am "Fix navigation bug"
Warning: The
-aflag only stages tracked files. New files must be added withgit addfirst.
Viewing History
git log - View Commit History
Shows the commit history:
# Full log
git log
# Compact one-line format
git log --oneline
# Show last 5 commits
git log -5
# Show commits with graph visualization
git log --oneline --graph --all
# Show commits by specific author
git log --author="John"
# Show commits from last 2 weeks
git log --since="2 weeks ago"
Example output:
commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0
Author: Vikash <vikash@example.com>
Date: Mon Jan 15 10:30:00 2026 -0500
Add user authentication feature
commit b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0u1
Author: Vikash <vikash@example.com>
Date: Sun Jan 14 15:45:00 2026 -0500
Initial commit
Viewing Changes
git diff - Show Differences
Shows changes between commits, branches, or files:
# Show unstaged changes
git diff
# Show staged changes (ready to commit)
git diff --staged
# or
git diff --cached
# Show changes between two commits
git diff commit1 commit2
# Show changes for a specific file
git diff filename.txt
Working with Branches
git branch - Manage Branches
# List all local branches
git branch
# List all branches (including remote)
git branch -a
# Create a new branch
git branch feature-login
# Delete a branch (safe - won't delete unmerged changes)
git branch -d feature-login
# Force delete a branch
git branch -D feature-login
# Rename current branch
git branch -m new-name
git checkout / git switch - Switch Branches
# Switch to an existing branch
git checkout feature-login
# or (newer syntax)
git switch feature-login
# Create and switch to a new branch
git checkout -b feature-login
# or
git switch -c feature-login
# Discard changes in a file (careful!)
git checkout -- filename.txt
Merging
git merge - Combine Branches
# First, switch to the target branch (e.g., main)
git checkout main
# Merge feature branch into current branch
git merge feature-login
# Merge with a commit message
git merge feature-login -m "Merge feature-login into main"
Remote Operations
git remote - Manage Remote Connections
# List remotes
git remote -v
# Add a remote
git remote add origin https://github.com/username/repo.git
# Remove a remote
git remote remove origin
# Rename a remote
git remote rename origin upstream
git push - Upload Changes
# Push to remote
git push origin main
# Push and set upstream (first time)
git push -u origin main
# Push all branches
git push --all origin
git pull - Download and Merge Changes
# Pull changes from remote
git pull origin main
# Pull with rebase instead of merge
git pull --rebase origin main
git fetch - Download Changes Without Merging
# Fetch all branches from remote
git fetch origin
# Fetch a specific branch
git fetch origin feature-branch
Note:
git pull=git fetch+git merge. Usefetchwhen you want to review changes before merging.
Your First Git Workflow
Let's put it all together with a complete example:
# 1. Create a new project
mkdir my-website
cd my-website
# 2. Initialize Git
git init
# 3. Create some files
README.md
index.html
style.css
# 4. Check status
git status
# 5. Stage all files
git add .
# 6. Make your first commit
git commit -m "Initial commit: Add README, index.html and style.css"
# 7. Create a feature branch
git checkout -b add-styles
# 8. Make changes
style.css #added basic style for fonts
# 9. Stage and commit
git add style.css
git commit -m "Add basic stylesheet"
# 10. Switch back to main and merge
git checkout main
git merge add-styles
# 11. Connect to remote (if you have one)
git remote add origin https://github.com/username/my-website.git
# 12. Push to remote
git push -u origin main
Best Practices
Commit often: Small, regular commits are easier to track and roll back if something goes wrong.
Write clear commit messages. Go for the imperative mood, like “Add feature” instead of “Added feature.”
Work in branches: Keep your main branch stable and build new features in their own branches.
Pull before you push: Always run
git pullbeforegit push. It helps you dodge those annoying merge conflicts.Check your changes before you commit: Use
git diff --stagedto see exactly what you’re about to commit.Keep sensitive stuff out of your repo: Add passwords, API keys, and environment files to
.gitignoreso you don’t accidentally share them.
Sample .gitignore File
# Dependencies
node_modules/
vendor/
# Environment files
.env
.env.local
# Build outputs
dist/
build/
# IDE files
.vscode/
.idea/
# OS files
.DS_Store
Thumbs.db
# Logs
*.log
Common Mistakes to Watch Out For
Committing to the wrong branch
- It happens: Stash your changes with
git stash, switch to the right branch, then bring them back usinggit stash pop.
- It happens: Stash your changes with
Accidentally committing sensitive info
- Don’t let secrets slip into your repo: Add those files to
.gitignorebefore you commit. If something sneaks in, clean your history withgit filter-branchorBFG Repo-Cleaner.
- Don’t let secrets slip into your repo: Add those files to
Writing big, vague commit messages
- Keep it short and clear: Use this
pattern: <type>: <short description>— for example,fix: resolve login timeout issue.
- Keep it short and clear: Use this
Forgetting to pull before you push
- Stay synced: Always run
git pull --rebase origin mainbefore you push your changes.
- Stay synced: Always run
Force pushing to shared branches
- Just don’t: Never use
git push --forceon main or any shared branch. It’s a recipe for headaches.
- Just don’t: Never use
Conclusion
So, you’ve made it through the basics of Git. Here’s what sticks:
Git doesn’t just watch for little changes — it grabs full snapshots, which keeps things speedy and solid.
Everything you do kind of revolves around three main states: Modified →Staged→ Committed.
There are a handful of commands you’ll use all the time:
init, clone, add, commit, status, log, branch, checkout, merge, push, andpull.Branches let you try new ideas or work in parallel without messing up the main flow.
And don’t forget about remote repositories — that’s how you work with others and keep your stuff safe.
Sources:
Practice with interactive tools like Learn Git Branching
If you found this helpful, consider following for more developer tutorials and best practices.






