DEV Community: Abhishek Kumar

Git Basics Made Simple: Essential Commands Every Developer Should Know

Abhishek Kumar — Sat, 31 Jan 2026 21:04:50 +0000

Hello readers, Welcome back

In the previous blog, I shared the story related to the problems developers face without Git — the well-known pendrive problem. You understood why Git is important and how it helps us make our developer journey smooth.

If you are new, then you can checkout my first of this git series:
Blog 1 : Why git exist: the pendrive problem

In this blog, I’m going to teach you the basics of Git and Git commands with stories and in depth.

Blog Contents

What is Git?
Why Git is Used
Git Basics and Terminologies
Basic Commands of Git
- git init
- git add
- git commit
- git status
- git log
- git diff
- git revert
- git reset
  - git reset --hard
  - git reset --soft
Conclusion
What’s Next

What is git?

Git is a version control system that helps developers track their code. It keeps track of code changes in your project along with the author information of who made those changes.

It was developed by Linus Torvalds (the developer of Linux) in 2005. It was created to handle the complexity of the Linux project.

Why git is used?

To Time Travel: Yes, if you want to time travel, then use Git. Git keeps track of all your changes, and if you have made a mistake in the past, it allows you to go back to that code and fix it.
Smooth collaborations: Git helps you easily collaborate with your fellow developers, review their code changes, and work with the team without conflicts.
Rapid Development: Git allows developers to work on multiple independent features simultaneously using features like branching and merging.

Git Basics and Terminologies

Here are some core terminologies you should know before jumping into the commands:

Repositery: It is your project folder where all your code files exist.
Add: It means you have started tracking your file.
Commits: It means making your changes permanent.
Head: HEAD is a pointer to your latest commit.
Branch: A branch means separating different features from your main code.
Pull: Pulling code from a remote repository (GitHub, Bitbucket) and merging it into your local repository.
Fetch: Fetching code from a remote repository without merging it into your existing code.

Basic commands of Git

To use Git, first you need Git installed on your computer. You can install it from the Git website: https://git-scm.com/install/windows

To check whether Git is available on your computer or not, run this command:

To track your repository’s code changes, you have to initialize Git in your project. Here is our first command:

git init: Initializes an empty Git repository in your project.

Now, your code files are ready to be tracked by Git. Whenever you create a new file in your project, it will be marked as untracked (U), which means Git is not tracking that file.

To track the file, you have to run:

2. git add <file_name>: Adds the file to the staging area of Git. It means your file changes are under the surveillance of Git. The staging area is like a lobby where all the files that are being tracked by Git are placed.

If you have too many files to track or stage, then you can use git add . This will add all your untracked or modified files to the staging area.

Now, Git has started tracking your changes, and when you have finished making changes or reached a specific point, you need to make those changes permanent so that you don’t lose them. To do this, here is another command:

3. git commit -m <commit_message>: This command makes your changes permanent and removes your file from the staging area to the local Git repository.

Each time you make a commit, it creates a unique hash, and each commit has the address of its previous commit. As a new commit hash is created, HEAD moves to that commit.

The commit message is important; it should be precise about the changes you are committing. In this command, -m means message. If you don’t add a message, this command will open a file where you need to enter your message and then close that file.

To get the status of files in your project, such as modified or untracked, use this command:

4. git status: It gives the status of your files.

To see all the commit details, you can use this command:

5. git log: It shows the commit ID, author information, date, and time. It also shows which commit HEAD is pointing to.

You can also use git log --oneline to get a short summary. This will only include the short commit hash and the commit message.

6. git diff: This command shows the difference between two commits. It takes the commit hash as input.

In case no commit hash is provided, it will show the overall recent changes.

Until now, you are working smoothly and developing your features, but suddenly you encounter a bug in a commit. Now you need to revert that commit to run your project. To do this, there are multiple commands. One of them is:

7. git revert: It takes a commit ID and reverts the changes by adding a new commit. In this new commit, the buggy part added in the given commit is removed. HEAD is also moved to this new commit.

The advantage of this command is that you retain the history of the code fault and its resolution.

Another way is to move HEAD before the bug commit instead of adding a new commit. This will also remove the bug, but it will remove the history that the bug was introduced. For this, use the following command:

8. git reset:

git reset has multiple options—either you move HEAD while deleting all the changes (--hard), or you keep the changes in the staging area to be committed again (--soft).
- a. git reset — hard HEAD~1: This command moves HEAD one commit back and permanently deletes the changes along with the history. Use it at your own risk. Only use it when you know what you are doing.
- b. git reset — soft HEAD~1: This command moves HEAD one commit back and moves the changes to the staging area instead of deleting them. Now you can modify the files and fix the bug. After completing the fixes, commit again. This is safer than --hard.

conclusion

This brings us to the end of the Git basics and essential commands. By now, you should have a clear understanding of how Git tracks your code, manages changes, and helps you recover from mistakes confidently.

what's next

In the next blog, we’ll go deeper into Git’s file structure and explore what happens under the hood when you run these commands. Understanding this will make Git feel less magical and more logical.

If you found this blog helpful, do share it with others and feel free to drop your feedback. Your feedback helps me improve and write better content for you.

Why GIT Exists: The Pendrive Problem

Abhishek Kumar — Sat, 31 Jan 2026 20:41:41 +0000

If you are a developer, you must already be aware of Git and GitHub. But do you know

why Git was created?
What problems existed before Git?
And how was the world of coding managed before version control systems?

In this article, you’ll find answers to all these questions.

How Was the World of Coding Before Git?

Let’s go back in time and imagine a world without Git.

You are a developer working smoothly on a project. One day, you need help to develop a new feature, so you ask your developer friend, Rishi. Rishi agrees and asks for the code.

To share the code, you zip the project, copy it to a pendrive, and hand it over to him. Rishi develops the feature, zips the updated code along with the existing code, and returns the pendrive to you.

When you unzip the project, the first problem you notice is that there is a lot of code, and you have no idea which part was written by whom. Since the feature works fine, you ignore this issue and continue working with the updated code.

A few days later, you discover a bug in the feature your friend wrote. You ask Rishi to fix it. Once again, you copy the entire project to the pendrive and give it to him. He fixes the bug, patches the code, and returns the pendrive.

Now you know the code has changed — but you don’t know exactly what changed or where. To understand the modifications, you have to sit with your friend, discuss the changes line by line, and this takes time.

Another major issue is conflicts and wasted time. Sometimes, while fixing a bug, some important code gets modified or removed without your knowledge. As a result, you may have to debug the entire project again.

Problems Faced Before Git

By now, you can clearly see the problems developers faced:

Code Sharing: Every time a feature needed to be developed or a bug needed fixing, the code had to be zipped and shared via a pendrive repeatedly.
Difficult to Track Code Changes: You had no visibility into what changes your friend made or which files were modified.
Hard to Collaborate: If multiple developers needed to work on the same project, tracking changes became almost impossible. Also, only one person could work at a time — the one who had the pendrive.

Thinking About a Solution

Now let’s think about solving these problems.

The first challenge is to track who made what changes. To solve this, imagine creating a software system that:

Tracks code changes
Stores the author of each change
Shows differences between old and new code
Maintains version history

This solution would address the first two problems: tracking changes and identifying contributors.

However, collaboration is still an issue. Only one developer can work at a time because the source code still exists in a single physical location.

To solve this, you think of creating a single source of truth for the code. You purchase a server, install this code-tracking system on it, and upload your entire project there.

Now, your friends can pull the code from the server, work independently, and push their changes back. Other developers can then pull the updated code from the same server.

This is exactly what Git (the code-tracking system) and GitHub (the hosted server) do.

The Birth of Git

Git was created by Linus Torvalds to manage the Linux project. As Linux grew larger day by day, tracking changes became extremely difficult. To solve this problem, Linus developed Git — a distributed version control system (VCS).

Alternatives to Git

AWS CodeCommit
Apache Subversion
Unity Version Control
Fossil
Concurrent Versions System (CVS)

Alternatives to GitHub

Bitbucket
GitLab
Gitea
Codeberg

This was all about why Git was needed — the problems developers faced before version control systems and how Git solved those challenges. Understanding this background makes it much easier to appreciate Git’s power and importance in modern software development.

In the next article, we’ll dive into how Git actually works, explore its internal concepts, and take a closer look at the folder structure of the .git directory to understand what happens behind the scenes.