Git for Beginners: How I Stopped Breaking Into a Cold Sweat at the Word "Merge Conflict"

8 min read

Or a survival guide to the world of version control systems

I still remember my first day as an intern. I had just finished a JavaScript course, built a couple of pet projects, and felt like a Jedi. Then my tech lead said something that made my stomach drop:

“Clone the repo, create a branch, and open a pull request.”

I nodded confidently, walked to the bathroom, and spent 15 minutes Googling “what is a pull request.”

If you’re in that same boat right now — this article is for you. We’ll break down Git without the scary jargon, using real examples, and by the end, you’ll understand why modern web development simply doesn’t work without it.

What Is Git and Why Do You Need It?

Imagine you’re writing your thesis. First, you save it as thesis.docx. Then you make edits — save as thesis_final.docx. Then your advisor asks you to bring back a paragraph from the first version — and suddenly you have thesis_final_actually_final_v2_fixed.docx.

Git is the tool that makes those filenames obsolete.

It remembers every single change you make to your code, lets you revert to any previous version, and — most importantly — allows multiple developers to work on the same project simultaneously without overwriting each other’s work.

Installation and First Steps

If Git isn’t installed yet:

  • macOS: brew install git (or download from the official site)
  • Windows: download from git-scm.com — it comes with the handy Git Bash terminal
  • Linux: sudo apt install git

Once installed, introduce yourself to the system. Git uses this info to label your changes:

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

To check if everything worked:

git config --list

Essential Commands: Your Starter Kit

Let’s imagine you’re starting a new project. I’ll use a folder called my-project — feel free to follow along.

1. Initialize a Repository

mkdir my-project
cd my-project
git init

The git init command creates a hidden folder called .git. This is where Git stores all version history. Now Git is “watching” this folder.

2. Your First Commit

Create an index.html file with some content:

<!DOCTYPE html>
<html>
  <head>
    <title>My First Git Project</title>
  </head>
  <body>
    <h1>Hello, World!</h1>
  </body>
</html>

Now you need to “commit” this file. This happens in two steps:

git add index.html        # 1. Add the file to staging area
git commit -m "Create homepage"   # 2. Save the changes with a message

Golden rule: commit messages should be meaningful. Don’t write “fix” — write “Fix form submission bug on contact page.” Your future self will thank you.

3. Check Status

The most useful command for beginners:

git status

It shows you:

  • which files have changed,
  • which are staged for commit,
  • which aren’t being tracked yet.

Get in the habit of running git status after every action. It’s like checking your rearview mirror — always a good idea.

Branches: Why This Is Genius

Branches are what make Git truly magical.

Think of your project as a book. The main branch (main or master) is the published version that users see.

You want to add a new chapter. Instead of editing the published book directly, you create a draft — a separate branch. You experiment, make mistakes, rewrite. When everything is ready, you merge the draft back into the main book.

How It Looks in Commands:

# View all branches (current one is marked with an asterisk)
git branch

# Create a new branch
git branch feature/add-header

# Switch to that branch
git checkout feature/add-header

# Or combine both: create and switch
git checkout -b feature/add-header

Now you’re in the new branch. You can change code as much as you want — the main branch stays untouched.

When your work is ready:

git add .
git commit -m "Add site header"
git checkout main          # switch back to main
git merge feature/add-header   # merge the changes

To delete a branch you no longer need:

git branch -d feature/add-header

Merge Conflict: The Fear Itself

Sooner or later, this will happen. You try to merge branches, and Git throws something terrifying about a conflict. The world is ending. You’ve broken the project.

But a conflict is actually normal. Git is simply saying: “I don’t know which code is correct — you need to decide.”

Conflict Scenario

Let’s say you and a colleague (or just you in two different branches) changed the same line in the same file.

You run git merge and see:

Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

Open index.html and you’ll see:

<<<<<<< HEAD
<h1>Hello, World!</h1>
=======
<h1>Welcome to my site!</h1>
>>>>>>> feature/new-header

Git added markers:

  • <<<<<<< HEAD — what’s currently in your branch
  • ======= — separator
  • >>>>>>> feature/new-header — what’s coming from the branch you’re merging

What to Do?

  1. Don’t panic. Your code is still there.
  2. Edit the file manually — keep what you need, remove what you don’t.
  3. Delete all the markers (<<<<<<<, =======, >>>>>>>).

Let’s say you want to keep both:

<h1>Hello, World!</h1>
<h1>Welcome to my site!</h1>
  1. Save the file.
  2. Complete the merge:
git add index.html
git commit -m "Resolve conflict in header"

That’s it! Conflict resolved — you’re a hero.

GitHub: Cloud Storage for Code

Git runs on your computer. GitHub (or GitLab, Bitbucket) is a cloud service where repositories live on a server.

Why this matters:

  • Backup — your code is safe even if your laptop dies
  • Collaboration — your whole team works from the same repository
  • Portfolio — employers look at your GitHub

Essential Remote Commands:

# Clone (download) an existing repository
git clone https://github.com/username/repo.git

# Link your local repo to a remote one
git remote add origin https://github.com/username/repo.git

# Push changes to GitHub
git push origin main

# Pull changes from GitHub
git pull origin main

A Typical Day in a Developer’s Life

To tie everything together, here’s how a normal workday looks:

# Morning: get the latest code
git checkout main
git pull origin main

# Create a branch for today's task
git checkout -b feature/fix-button

# ... work, write code, save periodically ...
git add .
git commit -m "Fix button submission bug"

# ... maybe need to pull latest changes from main ...
git checkout main
git pull origin main
git checkout feature/fix-button
git merge main   # (conflicts might happen — resolve them)

# Evening: push code for review
git push origin feature/fix-button
# Then go to GitHub and open a Pull Request

Cheat Sheet: Commands to Memorize

  • git init — Create a new repository in current folder
  • git status — See what’s changed
  • git add <file> — Stage a specific file
  • git add . — Stage all changed files
  • git commit -m "message" — Save changes
  • git log — View commit history
  • git branch — List branches
  • git checkout -b <branch> — Create and switch to a new branch
  • git merge <branch> — Merge branch into current one
  • git clone <url> — Download a repository
  • git pull — Fetch and merge changes from remote
  • git push — Push changes to remote

Where to Go From Here

Git is one of those tools you learn best by doing, not by reading a thick book. Here are my recommendations:

  1. Git How To (githowto.com) — an interactive tutorial. 15 minutes and you’ll be confidently working with branches.

  2. Oh Shit, Git! (ohshitgit.com) — for those moments when you’ve already broken something and just need to fix it.

Wrapping Up

Git seems complicated for the first couple of days. It’s like learning to ride a bike: scary at first, you fall, you confuse the pedals, and then suddenly you can’t imagine life without it.

My biggest advice: don’t be afraid to experiment. Create a test folder, make a mess of branches, cause a conflict on purpose, then resolve it. It’s better to break a test repository than to be scared of breaking a real one.

You’ve got this. And if a conflict does hit you at 3 AM before a deadline — just remember this article and edit the file manually. Git is just waiting for you to tell it which code is right.