Organize history (rebase / cherry-pick)

01 / 08

Another way to integrate branches (git rebase)

In Chapter 2, you learned git merge as a way to combine branches.

git merge creates a merge commit with two parents, preserving the exact historical record that two branches crossed.

However, in large teams, frequent branching and merging can create a tangled web of commit lines.

"We want to keep our history clean, linear, and readable."

To meet that need, we use git rebase, introduced in this chapter.

02 / 08

git rebase — Changing the branch base

Rebase means to re-apply commits onto a new base.

Running git rebase main while on your feature branch temporarily sets aside your branch commits, and replays them one by one on top of the latest commit of main.

This produces a clean, linear history, just as if you had started your work from the latest main commit in the first place.

$ git switch feature$ git rebase mainSuccessfully rebased and updated refs/heads/feature.

03 / 08

Merge vs Rebase (How history is preserved)

The fundamental difference lies in how commit history is preserved.

git merge … Faithfully records that branches diverged and merged together. Creates a merge commit with two parents.
git rebase … Replays branch commits on top of the latest tip into a single line. No extra merge commits are created.

Neither command is inherently superior; teams choose based on branching workflows. Projects that prioritize readable, linear git logs widely adopt rebase.

04 / 08

Handling conflicts during a rebase

Just like merging, if your commits touch the same lines as the base branch, a merge conflict will occur during rebase.

However, you do not complete resolution using git commit.

1. Open and edit the conflicting files to resolve the conflicts
2. Run git add . to stage the resolved files
3. Run git rebase --continue to continue replaying subsequent commits

If you want to cancel the rebase entirely, run git rebase --abort to safely return to the exact state before starting the rebase.

$ git add .$ git rebase --continue

05 / 08

Never rebase shared commits (The Golden Rule)

There is an absolute golden rule respected by developers worldwide:

"Never rebase commits that have already been pushed and shared on a remote repository."

Because rebase changes parent pointers, it creates entirely new commit hashes, even if file diffs look identical. Rewriting shared public history forces everyone else's branches out of sync, causing severe collaboration issues.

Only rebase branches that exist strictly in your local environment and have not yet been pushed.

06 / 08

git cherry-pick — Selectively adopting commits

Another powerful history manipulation command is git cherry-pick.

git cherry-pick lets you extract a specific commit from another branch and apply it to your current branch.

For example, if you fixed an urgent bug midway through a large, unreleased feature branch, you can cherry-pick just that bugfix commit into main immediately without waiting for the rest of the feature to finish.

$ git switch main$ git cherry-pick c3b1e2a[main a4f2c1d] fix critical bug

07 / 08

Resolving conflicts in cherry-pick

Because cherry-pick applies commit changes onto the current working tree, conflicts can occur if the same file areas conflict.

The resolution process is identical to rebase:

1. Resolve the conflicting lines in the file
2. Run git add . to stage the changes
3. Run git cherry-pick --continue to complete the commit

To cancel and restore cleanly, run git cherry-pick --abort.

08 / 08

Summary of history manipulation commands

You now command the complete suite of history manipulation tools:

git rebase <branch> … Rebase current branch onto the tip of the specified branch
git rebase --continue / --abort … Resume or safely abort a rebase
git cherry-pick <commit-id> … Selectively apply a specific commit to the current branch
git cherry-pick --continue / --abort … Resume or safely abort a cherry-pick

Let's practice with the basic exercises!