Git for Beginners: Basics and Essential Commands
Git.
You’ve probably heard this word many times since the day you started learning development.
You see it in almost every developer’s resume.
You see it in almost every job description.
And very quickly, you realise that Git is not optional. It’s a must-have skill in a developer’s day-to-day coding life.
So in this blog, let’s keep things simple and talk about:
What Git is
Why Git is used
Why it’s important in a developer’s workflow
Basic Git Terminologies
and some commonly used Git commands
What is Git?
Git is an open-source distributed version control system.
In simple words, Git helps you:
Track changes in your code
See what changed
Know who made the change
And understand when it happened
If a bug appears or something breaks, Git allows you to go back to an older version of the code and fix things without panic.
Most beginners don’t fully realise the true value of Git when working on small projects alone. But once you start working on larger projects or with other developers, Git becomes extremely useful.
So when was it built? Git was created in 2005 by Linus Torvalds (yes, the same person who created Linux!), and it was initially built to manage the development of the Linux kernel. From the start, the goals were clear: speed, performance, a fully distributed system, and the ability to handle large projects. And look where we are now, almost 96% of developers are using Git in 2026!
Why is Git Used?
You might be wondering, "Why are we using Git? What were developers doing before Git was built?"
Well, before Git came along, developers were using other version control systems like SVN (Subversion), CVS, and Mercurial. But here's the thing: when I started as a frontend developer, I didn't even know version control existed! I was just using FileZilla (an FTP tool) to upload files directly to the server. The transfer itself wasn't much of a hassle, but I had NO way of tracking what changes were made.
When multiple developers were working on the same project, it was chaos. We had to remember server IPs, passwords, and had to install FTP software on each system. And the worst part? When bugs occurred, we had no idea who changed what and when! There was no history, no way to go back to a working version.
When I finally learned Git, everything changed. It became so much easier to solve bugs because we knew exactly when, who, and what changes were made. We could revert to previous versions until we found the solution. No more "it was working yesterday, what happened?!" moments.
So why did Git become THE version control system? Because compared to older systems like SVN:
Git is distributed (everyone has the full history, not just a central server)
It's much faster
Branching and merging are super smooth (we will talk about it in a bit)
GitHub (a Git Server) made it accessible and popular
Now, almost all developers use Git in their day-to-day coding life to make their workflow seamless and stress-free.
Git Basics and Core Terminologies
Now that we know what Git is and why it’s used, let’s understand some core Git terms you’ll hear all the time.
Repository (Repo)
A repository is a project folder that Git is tracking.
There are two types of repositories:
Local repository (on your system)
Remote repository (on a Git server like GitHub)
When you initialise Git inside a folder, Git creates a hidden .git folder. This folder stores information about:
Files
Commits
Branches
The complete change history
Usually, you create a local repository first and then push it to a remote repository. So even if something happens to your system, you can always clone the project again from the remote server.
Commit
A commit is like saving your work.
Once you finish a piece of work, you commit the changes. A commit creates a snapshot of the project at that moment.
This helps other developers get the latest version of the code. Conflicts usually happen when multiple people change the same lines of code, which is why committing regularly is a good habit.
Branch
A branch is a parallel version of your project.
Instead of working directly on the main branch, developers usually create separate branches for features or fixes. Once the work is reviewed, it gets merged back into the main branch.
This keeps the main codebase clean and stable.
Pull
Pull means getting the latest changes from the remote repository into your local system.
Push
After committing your changes locally, push is used to send those commits to the remote repository.
Clone
Clone means creating a copy of an existing remote repository on your local system. This is different from creating a branch.
HEAD
HEAD points to the current commit you are working on. It simply tells Git where you are right now in the project history.
Common Git Commands
git init
Initialises Git inside an existing folder by creating the .git directory and starting change tracking.
git init
git status
Shows the current status of your repository:
Modified files
Staged files
Untracked files
git status
git add
Adds files to the staging area (files that are ready to be committed).
git add <filename>
You can also see:
git add .
This command adds all the files to the staging area.
git commit
Saves the staged changes permanently.
git commit -m "commit message"
You can also use:
git commit -am "message"
This command stages and commits only already-tracked files (it does not add new files).
git log
Shows the commit history:
Who made the commit
When it was made
git log
git diff
Shows the difference between two commits.
git diff <commit-hash> <commit-hash>
git pull
Fetches the latest code from the remote repository and merges it into your local branch.
git pull
git push
Pushes your committed changes to the remote repository.
git push
git reset
Mainly used to undo changes. In simple terms, it helps you move your project back to an earlier state. For example, if you added files to staging by mistake, you can unstage them:
git reset
This removes files from the staging area but does not delete your code.
git reset --hard
This is a powerful command, so it should be used carefully.
git reset --hard
This command:
Removes changes from staging
Removes changes from your working directory
And resets everything back to the last commit
In short, it discards all local changes permanently.
Use this only when:
You are sure you don’t need the changes
Or you want a completely clean state
Beginner tip: Avoid using
git reset --hardon shared branches likemain.
git revert
The safest way to undo changes, especially in shared projects.
Instead of deleting history, it:
Creates a new commit
That reverses the changes of a previous commit
git revert <commit-hash>
Here's How You'd Start A Simple Project From Scratch
mkdir demo-project
This command creates a new folder named demo-project. At this point, it’s just a normal folder on your system, nothing related to Git yet.
cd demo-project
This moves you inside the demo-project folder. From now on, any command you run will affect this folder.
git init
This command tells Git:
Start tracking this project.
Git creates a hidden .git folder inside demo-project. This .git folder stores all the information about:
Commits
Branches
And change history
After this step, your folder officially becomes a Git repository.
echo "hello world" > index.html
This creates a new file called index.html and writes hello world inside it. You now have a file in your project, but Git is not tracking it yet.
git add index.html
This command tells Git:
I want to include this file in my next commit.
The file is moved to the staging area, which means it’s ready to be saved.
Think of staging as selecting files before saving.
git commit -m "Create index.html"
This command saves the staged changes.
Git creates a snapshot of your project at this moment and stores it in the repository history.
The message "Create index.html" helps explain what this commit contains.
After this step, your change is safely recorded.
git log
This command shows the commit history.
You’ll see:
Commit ID (hash)
Author
Date
Commit message
This is useful when you want to review changes or go back to an older version.
What Just Happened? (Quick Summary)
You just:
Created a project
Initialised Git
Added a file
Saved your first commit
Viewed the commit history
This is the basic Git workflow you’ll repeat in almost every project.
These are the basic steps, from initialising Git to committing your first file.
Whenever you work on a shared project, always pull the latest code before starting your work.
This simple habit avoids most Git-related issues.
Once you’re comfortable with these commands, you can also use tools like GitHub Desktop to do the same things with just a few clicks.
Before you go, I would love to know if you’re learning Git, what part confused you the most?
If you found this blog helpful, give it a like and share it with other beginners learning Git.
Happy coding!
