Comprehensive Git Guide for Beginners

I wrote this guide for two reasons: to have a personal reference I can come back to, and to have something concrete to share with friends and colleagues who are just getting started with Git.

One thing upfront: learn the CLI. Not because GUI tools are bad — some are genuinely great — but because the CLI forces you to understand what's actually happening. When something goes wrong (and it will), knowing the commands is the difference between fixing it in 30 seconds and spending an hour confused.

1. Installing Git & Setting Up Your Account

Download

Keep default settings during installation unless you know what you want to change. Restart your terminal after installation.

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

The --global flag applies these settings to all repositories on your machine. Git attaches your name and email to every commit you make — if it doesn't match your GitHub account, commits won't show up correctly under your profile.

2. Core Concepts

Before touching any commands, understand what you're working with:

Commit — a saved snapshot of your code at a specific point in time.
Branch — an independent line of development. You can work on a feature in its own branch without touching anything else.
Remote — a copy of the repository on a server (GitHub, GitLab, etc.).
Staging Area — a preparation zone. Files go here before they're committed.
Push — send your local commits to the remote.
Pull — bring commits from the remote down to your local machine.
Merge — combine changes from one branch into another, creating a merge commit.
Rebase — replay your branch's commits on top of another branch's latest commit, keeping history linear.

Branches are how you keep work organized. Main branch stays stable. Everything else gets its own branch.

3. Checking What's Going On

git status       # what's changed, what's staged, what's untracked
git branch       # list local branches, * marks the current one

Before creating a new branch or checking out, always run git status first. Knowing where you are before you move prevents a lot of confusion.

4. The Core Loop: Add → Commit → Push → Pull

This is what you'll do dozens of times a day.

Stage your changes

git add .

This stages all changed files. Use git add <filename> if you want to stage specific files only.

Commit

git commit -m "Clear description of what you changed"

Write commit messages that mean something. "fix bug" tells you nothing in three months. "fix cart total not updating when quantity changes" is actually useful.

Push

git push origin main

First push of a new branch requires setting upstream:

git push -u origin <branch-name>

After that, git push alone is enough.

Pull

git pull origin main

Pull before you start working. Pull before you push. Pull frequently. This keeps your local copy in sync and prevents the kind of conflicts that waste an afternoon.

5. Working with Branches

Create and switch to a new branch

git checkout -b feature-login

This creates the branch and switches to it in one command.

Switch to an existing branch

git checkout feature-login
# or
git switch feature-login

Commit and push on a branch

git add .
git commit -m "Add login form validation"
git push origin feature-login

Never commit directly to main for anything that matters. Create a branch, do the work, merge it in.

6. Rebase vs Merge

This is where people get confused. Both combine changes — they just do it differently.

Starting situation:

main:      A──B──C──G
feature-x:    B──D──E──F

Rebase

git checkout feature-x
git fetch origin
git rebase origin/main

Result:

main:      A──B──C──G
feature-x:          D'──E'──F'

Your branch's commits (D, E, F) are replayed on top of main's latest commit. History looks linear — one straight line. D', E', F' are new commits with the same changes but different hashes.

Use rebase when: you want clean, readable history. Good for feature branches before merging into main.

Merge

git checkout feature-x
git merge origin/main

Result:

main:      A──B──C──G
feature-x:    B──D──E──F──M

Merge creates a new commit M that combines both histories. The original commits stay exactly as they were.

Use merge when: you want to preserve the full history of what happened and when.

Note: Never rebase commits that have already been pushed to a shared remote branch. Rebase rewrites commit hashes — if others have those commits, it creates conflicts.

7. Pull Requests

After pushing a feature branch, open a Pull Request on GitHub to merge it into main.

git push origin feature-login

Go to GitHub → your repo → you'll see a "Compare & pull request" banner. Create the PR, add a description, get it reviewed, merge it.

After merging:

git branch -d feature-login                    # delete locally
git push origin --delete feature-login         # delete on remote

Clean up branches after merging. Stale branches are noise.

8. Common Workflows

Add an existing local project to GitHub

cd /path/to/your/project
git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin git@github.com:username/repo-name.git
git push -u origin main

Create a new project from scratch

mkdir my-project && cd my-project
git init
echo "# My Project" >> README.md
git add README.md
git commit -m "Initial commit"
git branch -M main
git remote add origin git@github.com:username/my-project.git
git push -u origin main

Clone an existing repo

git clone git@github.com:username/repo-name.git
cd repo-name

9. Keeping a Feature Branch Updated

While you're working on a branch, main keeps moving. Update your branch regularly.

With rebase (cleaner):

git checkout feature-login
git fetch origin
git rebase origin/main

With merge (safer if others are on the same branch):

git checkout feature-login
git merge origin/main

Do this before opening a PR. Merging an outdated branch into main is how conflicts happen.

10. Resolving Conflicts

When Git can't automatically merge two versions of a file, it marks the conflict:

<<<<<<< HEAD
your version
=======
their version
>>>>>>> origin/main

Open the file, decide what the correct version should be, remove the conflict markers, then:

git add <filename>
git rebase --continue    # if you were rebasing
git commit               # if you were merging

Conflicts feel intimidating the first few times. They're actually straightforward once you understand what you're looking at.

11. Habits That Prevent Problems

Pull before you start working, every time.
Make commits small and focused — one logical change per commit.
Use descriptive branch names: feature/user-auth, bugfix/cart-total-calculation, hotfix/broken-image-url.
Update your feature branch from main before opening a PR.
Delete branches after merging.
Never force-push to main or any shared branch.

12. Visual Summary

main:      A──B──C──G
feature-x:    B──D──E──F

After rebase:
main:      A──B──C──G
feature-x:          D'──E'──F'

After merge:
main:      A──B──C──G──M
                      ↑
              merges feature-x

That's the mental model. Keep it somewhere you can refer to when things get confusing.