What Git is and why you can’t work with code without it

There is a situation everyone who has ever written something more complex than a single line knows well: you changed a file, everything broke, and you don’t remember exactly what you changed. Should you have deleted that line or left it. And what if the new version works worse than the previous one. And how do you get back to what worked yesterday.

Git is a version control system. It records the history of every file in your project. Every time you make a commit, Git captures exactly which lines changed, who did it, and why. It is literally a time machine for code.

Even if you work alone — you need Git. If you work in a team — it is as essential as air.

The problem: how people worked before Git

Before version control systems, things looked roughly like this:

• site.zip, site_v2.zip, site_final.zip, site_ACTUALLY_final.zip — endlessly; or even worse:
• copying entire folders with dates in their names;
• comments like “I changed the header but don’t touch the footer” in chat;
• when something broke — spending a long time finding the version that worked, and not always succeeding.

Git solves all of these: history is stored inside, no need to duplicate files with comments, and if something breaks — you can roll back to any saved state.

How this works in plain language

Git works on a simple model. Imagine three zones:

Working directory

This is what you see in your file manager: the project files you are editing. You write, delete, add code here.

Staging area (index)

This is the “commit bin” — where you decide which changes you want to save. Not every file in your working directory has to go into a commit. You choose only the ones that are ready.

Local repository

This is where all commits live — the full history of saved states. Each commit has a unique ID, a message, an author, and a date. You can go back to any of them.

The flow looks like this:

1. Edit files in the working directory.
2. Add changes to staging: git add.
3. Commit: git commit — and Git records the state.
4. (Optionally) Push to a remote repository: git push.

Basic commands everyone needs

You don’t need to learn everything at once. Here is the minimum to start:

Getting started

git init                  # initialize a new repository in the current folder
git clone URL            # copy an existing repository from GitHub / GitLab
git config --global user.name "Your Name"       # set name for commits
git config --global user.email "email@example.com"  # set email

Daily work

git status                # what changed since the last commit
git add file.txt          # stage a file for the next commit
git add .                 # stage all changes
git commit -m "description"  # save changes with a message
git log                   # view commit history

Working with a remote repository

git remote add origin URL  # link to a remote repository
git push origin main       # push changes to the server
git pull origin main       # fetch changes from the server

Branches

git branch                  # list all branches
git branch new_feature      # create a new branch
git checkout new_feature    # switch to another branch
# or use a shortcut:
git checkout -b new_feature # create and switch in one command
git merge new_feature       # merge changes from new_feature into current branch
git branch -d new_feature   # delete the branch after merging

Why branches exist

A branch is a separate line of development. Say you are working on a website. Right now there is the main branch called main — this is the stable, working version.

Now you want to add a new button but are not sure it will work out. Instead of breaking main, you create a branch:

git checkout -b feature/new-button

You work in this branch: make changes, commit. When it looks good — merge into main:

git checkout main
git merge feature/new-button

If something went wrong — just delete the branch, and main stays clean. Zero chaos.

In a team this is even more useful: each developer works in their own branch and doesn’t block anyone else. When a feature is done — it gets merged into the main version through code review or otherwise.

How a remote repository works

A remote repository is a copy of your project on a server — GitHub, GitLab, or any other. You need it for:

• Backup: if your machine dies, your code survives on the server.
• Team work: others can clone the repository and collaborate with you.
• Deploy pipeline: a server can automatically pull your code and deploy it to staging or production.

Common beginner mistakes

1. Not committing, or making commits too large

When you work for hours and commit everything in one git commit -m "fixes", nobody can understand what exactly changed, and you can’t roll back just part of the changes. Better to make small commits: one commit per logical change.

2. Ignoring .gitignore

Temporary files should not go into the repository: node_modules/, .env with secrets, compiled binaries, cache. That is what .gitignore exists for — a file listing file names Git should not track.

3. Committing secrets

Tokens, passwords, API keys must not end up in the repository. If they leak even once, you have to rotate all secrets and clean the history. Add .env to .gitignore before your first commit.

4. Fearing merge conflicts

A merge conflict is not a disaster. It is just a message: “Hey, two branches changed the same lines differently. Decide which version is correct.” You resolve it manually: open the file, see what Git marked as conflicting (<<<< and >>>>), keep the correct version, and commit.

5. Not using branches

Working directly in main is like riding a motorcycle without a helmet. Maybe nothing will happen. Or maybe you will crash. Make it a habit to create a new branch for every task.

Conclusion / action plan

Git is not complicated if you don’t try to learn everything at once. For most tasks, five commands are enough: add, commit, push, pull, status. Once those feel natural, everything else follows.

Here is what to do next:

1. Install Git (if not already installed) and set your name and email.
2. Initialize a repository in any existing code folder: git init.
3. Make your first commit: git add . and git commit -m "initial commit".
4. Create a separate branch for a new idea or change.
5. Sign up on GitHub and push your code to a remote repository.

Once you complete those five steps — you are already at the point where Git becomes your friend, not a monster.