Git for Beginners: Basics and Essential Commands

When I started learning development, I had one simple question:

Why is Git so important?

At first, it didn’t feel necessary. I was the only one writing code. Everything was working fine. But the moment collaboration started — or even small mistakes happened — I understood why Git exists.

Let me explain this with a simple story.

Life Without Git : Imagine a developer working on a project alone. The project grows day by day, features are added, bugs are fixed, and everything looks good.

One day, the developer needs help from another experienced developer.

There is no Git. No GitHub. No version control.

So what do they do?

The A developer zips the entire project folder and sends it to the B developer. The B developer extracts it, adds some new features, and sends the updated zip file back.

So far, this looks manageable.

But now, the A developer has no idea what code was changed by the B developer. There's no record of what was changed.

Then things start getting complicated.

After receiving the updated code, the A developer adds more features. At the same time, the B developer finds a bug in the feature they added earlier code.

Now what?

The B developer fixes the bug and sends the updated files again. But the A developer has already modified those same files. Both versions are different.

At this point, questions start piling up:

Which files should be replaced?
What code is newer?
What if replacing files removes newly added features?
What if a bug fix breaks something else?

Merging code manually becomes confusing, risky, and time-consuming. A simple collaboration turns into frustration.

The Biggest Problem: No Way Back

Now imagine something worse. A new feature is added, and suddenly the entire project breaks. The app no longer works. No one knows exactly what change caused the issue.

The new code is mixed.

This is where most developers realize something is missing.

This Is Why Git Exists

Git was created to solve exactly these problems.

Git keeps track of every change you make in your code. Every time you save a meaningful update, you create a commit. Each commit is like a snapshot of your project at that moment.

Nothing is deleted.
Nothing is lost.
You always have a full history.

As a developer question still comes up: How does Git track every change in a project?

so, The easiest way to understand Git commits is to think of them as game levels or save points.

You save your progress like this: Commit 1 → Commit 2 → Commit 3 → Commit 4

If everything works up to commit 3 but commit 4 breaks the code, there’s no panic. You can either revert commit 4 or reset the branch back to commit 3, depending on whether the commit was shared.

Now, collaboration becomes simple. Each developer works on their own changes, and Git intelligently tracks who changed what and where. When it’s time to combine those changes, Git helps merge them safely.

If there’s a conflict, Git clearly shows it instead of silently breaking the code.

Today, developers can be anywhere in the world. Developer A might be in one state, while Developer B is in another. To collaborate efficiently, we use GitHub, a platform where all the code is stored in a shared repository.

Because of this, there’s no longer a need to zip entire folders and send them through Google Drive or other file-sharing tools. Everyone works from the same codebase, and Git keeps everything organized and traceable.

What is Git?

Git is a distributed version control system that helps developers track changes in code, collaborate with others, and safely manage project history.

Git was created by Linus Torvalds (the creator of Linux) to manage large codebases efficiently.

Why Git is Used

Git is used because it solves common problems developers face:

Track changes over time: You can see who changed what and when.
Undo mistakes: If something breaks, you can revert to an earlier working version.
Experiment safely: Create branches to try new features without affecting the main project.
Collaborate easily: Merge contributions from multiple developers without losing anyone’s work.
Work offline: Every developer has the full project history on their computer.

Git Basics and Core Terminologies

To understand Git, you need to know a few key terms:

Repository (repo): A repository is the folder that holds your project and its version history. It can be local (on your computer) or remote (on GitHub, GitLab, etc.).
Commit: A commit is like a snapshot of your project at a specific point in time. It records what changed and why, so you can revisit it later.
Branch: A branch is a parallel timeline of your project. The default branch is usually called main or master. Branches let you experiment without touching the main project.
HEAD: HEAD is a pointer that shows the current branch and commit you are working on. When you commit, HEAD moves forward to the new commit.
Staging Area: Before committing changes, Git uses a staging area to prepare snapshots. Only files in the staging area will be saved in the next commit.

Common Git Commands and How They Work

Let’s see Git in commands such as:

Initialize a repository: This creates a new Git repository in your project folder. It’s the starting point for version control.
```
 git init
```
Check the repository status: Shows which files have changed and which are ready to commit.
```
 git status
```
Stage changes for commit: Adds the changes to the staging area. You can also stage all changes with git add .
```
 git add filename
```
Commit changes: Records a snapshot of the staged files. Always write clear messages so you remember what changed.
```
 git commit -m "Describe your changes"
```
View commit history: Shows a list of all commits with their messages, authors, and unique IDs.
```
 git log
```
Undo changes in the working directory : This discards changes in a file that haven’t been staged yet.
```
 git checkout -- filename
```
Git reset filename: Removes a file from the staging area but keeps your changes in the working directory.
```
 git reset filename
```
Revert a commit: Creates a new commit that undoes a previous commit without deleting history. Safe for shared branches.
```
 git revert <commit-id>
```
Reset to a previous commit: Moves HEAD back to a previous commit and discards all changes after it. Be careful—changes will be lost permanently unless backed up.
```
 git reset --hard <commit-id>
```
Show differences: See what has changed before staging or committing.
```
git diff
```

Remove a file from Git:

git rm filename
git commit -m "Remove file"

Stash changes temporarily: Useful if you want to save unfinished changes and switch branches.
```
git stash
git stash pop
```

Branching and Merging: Branches let you experiment safely:

git branch new-feature      # create a branch
git checkout new-feature    # switch to the branch

After finishing your work:

git checkout main           # switch back to main
git merge new-feature       # merge changes into main

If conflicts happen, Git will prompt you to resolve them manually.

A basic developer workflow using Git from scratch:

The first thing you need to do is install Git. Head over to git-scm.com and download the version for your operating system.

Installation is straightforward—just follow the defaults, and soon you’ll have Git ready on your computer. To make sure it worked, open your terminal and type:

git --version – this will show you the installed Git version.

Once Git is installed, it’s important to tell it who you are. Every time you commit changes, Git labels them with your name and email. Set this up with:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

With Git installed and configured, it’s time to start your first project.

Create a new folder for your project, maybe something like my-first-project, and navigate into it in your terminal. Then, turn it into a Git repository:

Have you seen .git folder ? Here is inside folder look like

Head:
- HEAD is a pointer to the current branch or commit you’re working on.
- When you commit, Git updates HEAD to point to the new commit.
- Example: If you’re on the main branch, HEAD points to refs/heads/main
- It tells Git: “This is your current working snapshot.”
refs:
- Stores pointers to branches and tags.
- Key folders:
  - refs/heads/ → your branches (main, feature-xyz)
  - refs/tags/ → tags for marking specific commits (like v1.0)
objects:
- This is the core of Git’s storage system. Every commit, tree (folder structure), and blob (file content) is stored here as a unique SHA-1 hash.
- Think of each object as a snapshot of a file or folder.
- This is how Git can track every change without storing full copies every time—only the changes.
index (aka staging area):
- This file represents the staging area.
- When you git add a file, Git updates the index with the file’s state at that moment.
- During git commit, Git takes the index and creates a new commit object in objects/.
logs:
- Git keeps a log of all movements of HEAD in logs/.
- Useful for recovering lost commits or understanding what happened in your repo.
- Example: git reflog reads this information.
config:
- Git configuration for the repository.
- Stores settings like remotes, default branches, or user info (overrides global settings if needed).
hooks:
- Scripts that run at certain events, like before committing (pre-commit) or after pushing (post-push).
- Developers use hooks for automation, like checking code style or running tests.
description
- A simple text file used mainly by GitWeb (a web interface) to describe the repository.

Working Directory → Staging Area → Objects in .git → HEAD → Branch → Commit History

Git doesn’t automatically track files—you need to stage them first. Here’s how you do it:

git status – see which files are untracked or changed.
git add index.js – stage the file to prepare it for committing.
git commit -m "initial commit" – commit your staged changes.

Every time you make changes to your files, you repeat this process: edit, stage, and commit. Each commit is like a checkpoint in your project’s history.

You can always go back to an earlier commit if something goes wrong.

Eventually, you might want to share your project online, and GitHub makes this easy. After creating a repository on GitHub, you can link it to your local project:

git remote add origin https://github.com/yourusername/your-repo.git

connect your local project to GitHub and

git push -u origin main

push your commits online so others can see them.

And that’s basically the workflow in action: install, configure, initialize, track, commit, and push.

It might seem like a lot at first, but once you do it a few times, it becomes second nature. Git isn’t just a tool— it’s like a safety net for your projects and a way to keep your code organized from start to finish.