That's what I told myself when my college mate gave me a quick walkthrough over Git back in 2021 during lockdown. And I was like, why haven't I used this tool from my school days for my assignments, for my projects, for everything? I felt like every software where we save our work by pressing CTRL+S should have git built within it. Well, that was my introduction to git.
Prior to that, my playground folder (yeah, that's the name of my project folder, pretty cool right? :) used to look something like this. Multiple FINAL versions of the same file named like this.
![A computer file explorer window shows seven blue folders labeled: "college final project," "college final project [FINAL]," "fronend," "frontend 2," "portfolio site," "portfolio site final," and "portfolio site final 2." The sidebar has options like Home, Desktop, and Downloads.](https://cdn.hashnode.com/res/hashnode/image/upload/v1769534569223/5a7f1ceb-ff87-43be-8d53-1a06e87292ac.png)
If you've been there, you know the pain. Now, let me tell you about Git and how it changed everything for me.
What is Git?
Git is a version control system(VCS) that tracks changes in your files and helps you manage different versions of your projects.
Git works locally inside of your project directory by default. It keeps track of your changes in your project folder in a versioned manner without any fuzz. Exactly like you keep a snapshot(backup) of your PC/Laptop in case if it runs into a problem then you can restore from any point.
But here's the interesting part about its origin story that I find fascinating.
Git was created by Linus Torvalds in 2005. Yes, the same guy who created Linux. And here's the fascinating part - Git was actually a side project of his that he built while working on his main project, Linux itself. The Linux kernel development team was using a proprietary version control system called BitKeeper, but when they lost access to it due to licensing issues, Linus decided to build his own. And he did it in just a few weeks.
Why Git is Used?
Before Git, I used to create multiple copies of my files manually. Every time I wanted to try something new or make a significant change, I'd duplicate the entire folder. My desktop was a mess of folders named "project_backup", "project_backup_2", "project_old", and the classic "project_final_final_thisone".
Git solves this chaos beautifully. Here's why developers like us use it:
Version Control Without the Mess: Git keeps track of every change you make to your code. Want to see what your code looked like three weeks ago? Git has got your back. Made a mistake and want to go back? No problem. You don't need twenty copies of the same file with different names.
Collaboration Made Easy: When I started working on our final year project in my Diploma, Git became indispensable. Multiple people can work on the same project simultaneously without overwriting each other's work. You can work on your feature while your teammate works on theirs, and Git helps you merge everything together.
Experimentation Without Fear: Want to try out a crazy new idea but afraid you'll break your working code? With Git, you can create a separate branch, experiment all you want, and if things don't work out, your main code is still safe and sound.
Work from Anywhere: Since Git is distributed, you have the complete history of your project on your local machine. No need to be connected to a central server to see your project history or make commits.
Git Basics and Core Terminologies
Before diving into commands, let's understand some fundamental concepts that form the backbone of Git. Trust me, understanding these will make everything else click.
Git Repository (Repo): Think of a repository as a special folder that Git watches over. When you initialize a Git repository in your project folder, Git starts tracking all the changes happening inside that folder. It's like putting your project under surveillance, but in a good way. Your repository contains all your files plus a hidden .git folder where Git stores all the version history and metadata.
Tracked Files(Staging Area): Not all files in your repository are automatically tracked by Git. A tracked file is one that Git knows about and monitors for changes. When you create a new file, Git sees it as "untracked" until you explicitly tell Git to start tracking it using the git add <file_name> command.
Commit: Think of a commit as a snapshot of your project at a specific point in time. You created a file, made some changes in an existing file, and want to finalize those changes to the next version of the project. That's when you perform a commit, to finalize, locally. Each commit has a unique identifier (a hash) and contains a message describing what you changed. It's like taking a photograph of your project that you can always return to.
Branch: This is one of Git's most powerful features. A branch is essentially a parallel version of your repository. The default branch is usually called "main" or "master". Branch is what enabled me and my teammate to work on our respective parts and features at the same time, and merge them to the main one after it got finished. I could be working on adding a login feature in a "login-feature" branch while my teammate works on fixing bugs in a "bugfix" branch, and the main branch stays stable.
HEAD: HEAD is a pointer that tells you where you currently are in your Git repository. Most of the time, HEAD points to the latest commit of the branch you're currently on. When you switch branches, HEAD moves to point to that branch. It's like a "you are here" marker on a map.
Common Git Commands
Now that we understand the concepts, let's look at the commands you'll use every day. I'll walk you through them in the order you'd typically use them when starting a project.
git init
This is where everything begins. git init initializes a new Git repository in your current directory.
cd your-project-folder
git init
When you run this command, Git creates that hidden .git folder I mentioned earlier. Your project is now a Git repository. This is what I wish I'd done with my "playground" folder from day one.
git clone
But what if the project already exists somewhere, like on GitHub? Instead of git init, you use git clone to download an existing repository to your local machine.
git clone https://github.com/username/repository-name.git
This downloads the entire project, including all its history, to your computer. I use this every time I want to contribute to an open-source project or when starting work on a team project.
git status
This is probably the command I use the most. git status shows you the current state of your repository. Which files have been modified? Which files are staged? Which files are untracked?
git status
It's like asking Git, "What's happening right now?" The output tells you exactly where things stand, which is incredibly helpful when you're in the middle of making changes.
git add
Once you've made changes to your files, you need to stage them before committing. git add moves your changes to the staging area.
git add file-name
To add all modified files at once:
git add .
This is the step where you decide which changes you want to include in your next commit. I used to add everything at first, but now I'm more selective, making smaller, focused commits.
git commit
After staging your changes, you commit them to your local repository with a message describing what you did.
git commit -m "type your commit message here"
git commit -am "type your commit message here"
The -m flag lets you add a message right there in the command. Your commit message should be clear and descriptive. Instead of "fixed stuff", write "Fix login button alignment on mobile devices". Your future self (and your teammates) will thank you.
git log
Want to see the history of your project? git log shows you all the commits made to your repository.
git log
This gives you a detailed view, but I prefer:
git log --oneline
This gives you a compact, one-line summary of each commit. Much easier to scan through when you're looking for something specific.
git diff
Before committing, I often want to see exactly what I changed. git diff shows you the differences between your working directory and the staging area.
git diff
To see differences in staged files:
git diff --staged
This command has saved me countless times from committing debug code or console.log statements I forgot to remove.
git branch
Branches are where Git truly shines for project management. To see all branches:
git branch
To create a new branch:
git branch feature-branch-name
To switch to that branch:
git checkout feature-branch-name
Or do both in one command:
git checkout -b feature-branch-name
I create a new branch for every feature I work on. It keeps things organized and makes it easy to work on multiple things without them interfering with each other.
git push
You've made commits locally, but your teammates can't see them yet. git push uploads your commits to a remote repository like GitHub.
git push origin main
This pushes your "main" branch to the remote repository named "origin". The first time you push a new branch, you'll need:
git push -u origin branch-name
The -u flag sets up tracking, so future pushes from that branch can just be git push.
git reset
Made a mistake and want to undo a commit? git reset is your friend, but be careful with it.
To unstage files without losing changes:
git reset file-name
To undo the last commit but keep the changes:
git reset --soft HEAD~1
To completely discard the last commit and all its changes:
git reset --hard HEAD~1
I try to avoid --hard unless I'm absolutely sure, because it permanently deletes changes.
git revert
Unlike git reset, which rewrites history, git revert creates a new commit that undoes the changes from a previous commit. This is safer when working with shared branches.
git revert commit-hash
If you realize a commit broke something and others have already pulled your changes, git revert is the way to go.
git rebase
Rebasing is a more advanced technique that helps keep your branch history clean. When you rebase, you're essentially moving your branch to start from a different point.
git rebase main
This takes all your commits from the current branch and replays them on top of the main branch. It's great for keeping a linear history, but never rebase commits that you've already pushed to a shared repository, as it rewrites history and can cause problems for your teammates.
Wrapping Up
Looking back at my pre-Git days, I can't believe I managed without it. Git has become more than just a tool for code – I use it for my blog posts, documentation, configuration files, and even my thesis. That instinct I had back in 2021, that everything should have Git built in? I still feel that way.
The commands I've covered here are just the beginning. Git has a lot more to offer, but mastering these basics will take you far. Start simple, use it daily, and gradually you'll discover more powerful features as you need them.
If you're still saving files as "final_project_1", "final_project_2", it's time to stop. Initialize a Git repository, make your first commit, and never look back. Your future self will thank you for it.
I have always wondered what’s inside of .git folder and how git runs internally. Well more about that in my next blog.
Till then…
If you are looking for a more in-depth git tutorial, you can refer to the official git docs and our beloved ChaiDocs.
