DevToolsForYou
Text Processing

How to Use Git: Core Workflows

A practical guide to everyday Git usage — committing, branching, merging, resolving conflicts, and keeping a clean history.

3 min readUpdated Apr 11, 2026

The three areas of Git

Understanding Git's three areas prevents most beginner confusion. The working tree is the files you see on disk. The staging area (index) is a snapshot you are building up to become the next commit. The repository (object store) holds all past commits. git add moves changes from working tree to staging; git commit moves the staged snapshot into the repository.

text
Working tree  →  git add  →  Staging area  →  git commit  →  Repository
(edited files)                 (index)                          (.git/objects)

Writing good commit messages

The first line is a subject (50 chars or fewer), written in the imperative mood: 'Fix login redirect' not 'Fixed login redirect' or 'Fixes login redirect'. Leave a blank line, then a body explaining what and why (not how). Good messages make git log and git bisect much more useful.

text
Fix login redirect after password reset

After a successful password reset the user was redirected to /dashboard
instead of /login. The auth middleware was reading the stale session
before the session cookie was cleared.

Fixes #347

Branching strategy

Keep main/master always deployable. Create a short-lived feature branch for every piece of work, no matter how small. Name branches consistently: feature/add-export, fix/null-pointer, chore/update-deps. Delete branches after merging.

bash
git switch -c feature/add-csv-export  # create and switch

# ... make commits ...

git switch main
git merge --no-ff feature/add-csv-export  # preserve merge commit
git branch -d feature/add-csv-export

Merge vs rebase

Merge creates a merge commit that records where two branches joined. It preserves exact history. Rebase replays your commits on top of the target branch, rewriting their hashes for a linear history. Golden rule: never rebase commits that have been pushed to a shared branch — it rewrites history that others may have based work on.

bash
# Merge (preserves history, safe for shared branches)
git switch main
git merge feature/my-feature

# Rebase (linear history, only on local/private branches)
git switch feature/my-feature
git rebase main  # replays feature commits on top of main
git switch main
git merge feature/my-feature  # now a fast-forward

Resolving merge conflicts

When Git cannot automatically merge, it marks the conflicting sections in the file. Open the file, find the markers, decide what the correct version is, remove the markers, then stage and commit.

text
<<<<<<< HEAD
const timeout = 5000;    ← your version
=======
const timeout = 10000;   ← incoming version
>>>>>>> feature/longer-timeout

# 1. Edit the file to the correct version:
const timeout = 10000;

# 2. Stage the resolved file
git add src/config.js

# 3. Finish the merge
git commit

Undoing mistakes

bash
# Undo last commit but keep changes staged
git reset --soft HEAD~1

# Undo last commit and unstage changes (keep files)
git reset --mixed HEAD~1

# Discard uncommitted changes to a file
git restore src/file.js

# Create a new commit that reverses a past commit (safe for shared branches)
git revert <commit-hash>

# Find a commit that introduced a bug
git bisect start
git bisect bad          # current commit is broken
git bisect good v1.2.0  # this version was fine
# Git checks out midpoints; mark each as good/bad until it finds the culprit
Frequently asked questions

What is the difference between git fetch and git pull?

git fetch downloads changes from the remote into your local remote-tracking branches (origin/main) without modifying your working tree or local branches. git pull is fetch + merge (or fetch + rebase with --rebase). When in doubt, fetch first, inspect the diff, then merge manually.

When should I use git stash?

Stash when you need to switch branches but have uncommitted changes you are not ready to commit. It is a temporary shelf — not a substitute for commits. Stash frequently becomes a graveyard of forgotten work; prefer a WIP commit (git commit -m 'wip') that you amend or squash later.

Related guidesAll guides →