What "linear" means

A linear history has no merge commits - every commit has exactly one parent, and the history is a single line from the initial commit to HEAD. Bisect runs cleanly, blame is unambiguous, and git log reads top-to-bottom like a chronological narrative.

Why linear matters

Each merge commit complicates blame, bisect, and revert. With a linear history:

Reviewers are reading your story

A pull request is a story you tell about a change. Before opening it, take five to ten minutes to clean up the narrative. The result: faster reviews, fewer follow-up commits, and a history future-you will be glad to read.

Step 1: rebase onto main

git fetch origin
git rebase origin/main

Resolve any conflicts now, while the change is fresh. Reviewers should not see a merge commit from main in your branch.

Why rebase

Rebase rewrites your branch so it appears to start from the tip of another branch, replaying your commits one by one. The result is a linear history that reads like a story, instead of a railway map of merge commits. For long-running feature branches, periodic rebases keep the diff small and the conflicts manageable.

The basic rebase

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

If conflicts arise, Git pauses on each commit. Resolve, then continue:

Branch sprawl is real

After six months on an active project, git branch can list dozens of dead branches - merged features, abandoned experiments, hotfixes for releases nobody runs. Cleanup is a five-minute monthly habit that pays back compounded interest in clarity.

Listing merged branches

git checkout main
git pull
git branch --merged           # local branches already in main
git branch --no-merged        # the still-active ones

Bulk-deleting merged branches

The classic one-liner:

What amend does

git commit --amend replaces the most recent commit with a new commit that includes whatever you have currently staged, plus an optional new message. It does not "edit" the commit; it creates a new one with the same parent and updates the branch pointer.

The case for patch-mode staging

The default git add stages whole files. Real edits rarely come in whole-file units - you almost always have a mix of unrelated tweaks. git add -p walks you through each hunk and lets you decide what to include in the next commit.

Invoking patch mode

git add -p
# or, scoped to a specific file
git add -p src/checkout.js

Git presents each hunk and a prompt:

What is an atomic commit?

An atomic commit captures exactly one logical change. It compiles, passes its own tests, and can be reverted in isolation without breaking anything else. Atomic commits make code review pleasant, git bisect precise, and git revert safe.

The smell test

If you find yourself writing a commit message with the word "and" - "Add login and fix typo and refactor helper" - you are looking at three commits crammed into one. Split them.

The diff already tells you what

A commit message that says "Updated user controller" is wasted bytes - git diff already shows the user controller was updated. The valuable part of a commit message is the why: what problem does this solve, what alternatives were considered, what subtle assumption is the reader missing?

The seven-rule format

Tim Pope's classic seven rules still hold up:

Why branch names matter

Branch names are the first thing reviewers, CI systems, and future archaeologists see. A consistent convention turns git branch -a from noise into a structured catalogue. On a team of five, sloppy names are merely annoying; on a team of fifty, they cause merge conflicts, lost work, and confused reviewers.

The three-part pattern

The most widely adopted convention uses three slash-separated segments: type, identifier, short description.

Why aliases matter

Git aliases turn long, verbose commands into short, memorable shortcuts. Once you have a handful of aliases configured in your ~/.gitconfig, you stop fighting the CLI and start flowing through it. Most developers type the same five or six commands hundreds of times a day; aliases pay back the setup cost within hours.

Configuring aliases

Aliases live under the [alias] section of your Git config. You can add them with git config or by editing the file directly.