glossary

Git Rebase

A git operation that rewrites commit history by applying commits from one branch onto the tip of another, creating a linear history without merge commits.

explanation

Rebasing is one of two primary ways to integrate changes from one branch into another (the other being merging). When you rebase, git takes the commits from your current branch, temporarily sets them aside, fast-forwards to the target branch's tip, then reapplies each commit on top. The result is a linear history that reads as if each change was authored sequentially against the latest code. Interactive rebase (git rebase -i) is the more powerful form. It opens an editor where you can reorder, drop, squash, fixup, edit, or split commits. This is the primary tool for cleaning up a feature branch's history before merging — turning a series of WIP checkpoints into a coherent set of atomic commits. A critical rule of rebasing: never rebase commits that have been pushed to a shared branch. Rebasing creates new commit hashes, so anyone who has pulled the old version will experience duplicate commits and merge conflicts. The safe workflow is to rebase local work before pushing, and use merge or rebase + force-push only on branches you own exclusively.

examples

git rebase main # rebase current branch onto main

git rebase -i HEAD~5 # interactively rebase last 5 commits

git rebase --abort # abort the rebase in progress

git rebase --continue # continue after resolving conflicts

git rebase --onto main feature-branch # rebase from feature-branch onto main

how git-agent helps

git-agent produces clean, atomic commits from the start, so interactive rebasing for cleanup is rarely needed. When you do need to rebase, the conventional commit messages git-agent generates make the rebase todo list self-explanatory — each commit's purpose is clear at a glance.

brew install gitagenthq/brew/git-agent

FAQ

What is the difference between rebase and merge?

Merge creates a new merge commit that ties together two branch histories, preserving the exact timeline of when each commit was made. Rebase rewrites history by applying commits linearly on top of the target branch, creating a cleaner log but losing the original chronological context.

Why should I not rebase a shared branch?

Rebasing changes commit hashes. If others have based work on the old commits, they will have duplicate commits and merge conflicts when they pull. The golden rule is: only rebase commits that exist locally on your own branch.

Does git-agent use rebase internally?

No. git-agent works at commit time, not after the fact. It splits staged changes into atomic commits using git's staging mechanism rather than rewriting history with rebase.

Atomic commits Squash commits Git merge conflict