Skip to main content

Command Palette

Search for a command to run...

Git for Beginners: Basics and Essential Commands

Master version control fundamentals - Learn Git core concepts, essential commands, and developer workflows from scratch

Updated
10 min read
V

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

FeatureBenefit
DistributedEvery developer has a full copy of the repository
Local OperationsMost operations work offline - no network latency
Data IntegritySHA-1 checksums ensure nothing can be changed without Git knowing
BranchingLightweight branches make experimentation easy
SpeedOperations 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:

  1. Modified: You changed a file, but it’s not staged yet.

  2. Staged: You’ve flagged that changed file, so it’s ready for your next commit.

  3. Committed: Now it’s locked in, saved to your local Git database.

This leads to three main sections of a Git project:

SectionDescriptionState
Working DirectoryFiles you see and editModified
Staging Area (Index)Preview of your next commitStaged
Git Directory (.git)Where Git stores metadata and historyCommitted

Here’s how the basic Git workflow goes:

  1. Modify some changes to your files.

  2. Pick the changes you want to keep and stage them.

  3. 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 -s for 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 -a flag only stages tracked files. New files must be added with git add first.

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. Use fetch when 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 pull before git push. It helps you dodge those annoying merge conflicts.

  • Check your changes before you commit: Use git diff --staged to see exactly what you’re about to commit.

  • Keep sensitive stuff out of your repo: Add passwords, API keys, and environment files to .gitignore so 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

  1. Committing to the wrong branch

    • It happens: Stash your changes with git stash, switch to the right branch, then bring them back using git stash pop.
  2. Accidentally committing sensitive info

    • Don’t let secrets slip into your repo: Add those files to .gitignore before you commit. If something sneaks in, clean your history with git filter-branch or BFG Repo-Cleaner.
  3. Writing big, vague commit messages

    • Keep it short and clear: Use this pattern: <type>: <short description> — for example, fix: resolve login timeout issue.
  4. Forgetting to pull before you push

    • Stay synced: Always run git pull --rebase origin main before you push your changes.
  5. Force pushing to shared branches

    • Just don’t: Never use git push --force on main or any shared branch. It’s a recipe for headaches.

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, and pull.

  • 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:


If you found this helpful, consider following for more developer tutorials and best practices.