-
- Joined
- Mar 22, 2026
-
- Messages
- 320
-
- Reaction score
- 0
-
- Points
- 0
Git rebase is a powerful command that allows developers to rewrite commit history, offering a cleaner, more linear project history compared to
What is Git Rebase?
At its core,
The primary goal of
Rebase vs. Merge: When to Use Which?
Both
* Cons: Can create a "messy" history with many merge commits, especially in active development.
* Cons: Destructive (rewrites history), can be problematic on shared public branches.
General Rule of Thumb:
How
Let's imagine you have a
You want to bring the changes from
1.
2.
What happens under the hood:
The result looks like this:
Notice D' and E'. These are *new* commits. While they contain the same changes as D and E, their SHA-1 hashes are different because their parent commit has changed. This is why rebase rewrites history.
Common Use Cases for
1. Keeping a Feature Branch Up-to-Date
This is perhaps the most common use. Before merging your
This will apply your feature commits on top of the latest
2. Cleaning Up Your Commit History with Interactive Rebase (
Interactive rebase is incredibly powerful for refining your branch's history before pushing it or creating a pull request. It allows you to:
To start an interactive rebase, specify a base point. This is usually the commit *before* the first commit you want to modify. For example, to rebase the last 3 commits:
Or, to rebase your feature branch onto
Git will open your default text editor with a list of commits and instructions:
You can then modify the
Save and close the editor. Git will then guide you through combining commit messages if you squashed.
Potential Pitfalls and Warnings
The Golden Rule: Never Rebase Public History
This is the most critical rule. If you have pushed commits to a shared remote branch (e.g., a branch that others have pulled from), and then you rebase those commits, you rewrite their history. When others try to pull, Git will see diverging histories, leading to confusion and potential data loss for collaborators.
Consequence: Collaborators will have to
Force Pushing (
After rebasing a branch that you *have* pushed (but only if you are absolutely sure no one else has pulled it), you will need to force push to update the remote:
Resolving Conflicts During Rebase
Conflicts during rebase are common. When Git encounters a conflict:
1. It will pause the rebase process.
2. It will tell you which files have conflicts.
3. You need to manually resolve the conflicts in the affected files (just like a merge conflict).
4. After resolving,
5. Continue the rebase:
6. If you want to abort the rebase at any point:
Conclusion
git merge. While it can seem intimidating at first due to its history-altering nature, understanding its mechanics and common use cases is crucial for collaborative development and maintaining a tidy repository.What is Git Rebase?
At its core,
git rebase takes a series of commits from your current branch, "unwinds" them, moves them to a new base point, and then "replays" them on top of that new base. This effectively integrates changes from one branch into another by moving or combining commits, rather than creating a new merge commit.The primary goal of
git rebase is to maintain a linear project history. Instead of having crisscrossing merge lines, git rebase makes it look as if all development happened sequentially.Rebase vs. Merge: When to Use Which?
Both
git rebase and git merge are used to integrate changes from one branch into another, but they do so in fundamentally different ways:git merge: Integrates changes by creating a new "merge commit". This commit has two parent commits (the tips of the two branches being merged). It preserves the exact history of both branches, showing precisely when and where merges occurred.
* Cons: Can create a "messy" history with many merge commits, especially in active development.
git rebase: Integrates changes by moving or combining commits to a new base. It rewrites history by changing the parent of commits, making it appear as if the commits were made directly on the target branch.
* Cons: Destructive (rewrites history), can be problematic on shared public branches.
General Rule of Thumb:
- Use
git mergefor integrating changes into shared, public branches (e.g.,main,develop). - Use
git rebaseon your local, private feature branches to keep them updated with the main branch, or to clean up your commits before pushing them for review.
How
git rebase WorksLet's imagine you have a
feature branch based off main. Meanwhile, new commits have been added to main.
Code:
A -- B -- C (main)
\
D -- E (feature)You want to bring the changes from
main (C) into your feature branch without a merge commit.1.
git checkout feature2.
git rebase mainWhat happens under the hood:
- Git identifies the common ancestor of
featureandmain(which is commit B). - It then "rewinds" your
featurebranch, temporarily storing commits D and E. - It moves your
featurebranch's base to the tip ofmain(commit C). - Finally, it "replays" your stored commits (D and E) one by one on top of C.
The result looks like this:
Code:
A -- B -- C -- D' -- E' (main, feature)Common Use Cases for
git rebase1. Keeping a Feature Branch Up-to-Date
This is perhaps the most common use. Before merging your
feature branch into main, you want to ensure it has all the latest changes from main and resolves any conflicts locally.
Bash:
git checkout feature
git rebase mainmain. If conflicts arise, resolve them, git add ., and then git rebase --continue.2. Cleaning Up Your Commit History with Interactive Rebase (
git rebase -i)Interactive rebase is incredibly powerful for refining your branch's history before pushing it or creating a pull request. It allows you to:
- Squash commits: Combine multiple small, incremental commits into a single, more meaningful one.
- Reword commit messages: Fix typos or improve descriptions.
- Reorder commits: Change the sequence of commits.
- Drop commits: Remove unwanted commits entirely.
- Fixup commits: Similar to squash, but discards the commit's log message entirely, using the previous commit's message.
- Edit commits: Stop at a specific commit to amend it (e.g., add forgotten files).
To start an interactive rebase, specify a base point. This is usually the commit *before* the first commit you want to modify. For example, to rebase the last 3 commits:
Bash:
git rebase -i HEAD~3main interactively:
Bash:
git checkout feature
git rebase -i mainGit will open your default text editor with a list of commits and instructions:
Code:
pick f7f3f6d Add initial feature logic
pick 31010ab Fix a typo
pick a5f4b2c Implement another part of feature
# Rebase 6c44efb..a5f4b2c onto 6c44efb (3 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) for each commit
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# . create a merge commit using the original merge commit's message (or the one line given)
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#You can then modify the
pick command for each commit as needed. For instance, to squash the "Fix a typo" commit into the "Add initial feature logic" commit:
Code:
pick f7f3f6d Add initial feature logic
s 31010ab Fix a typo
pick a5f4b2c Implement another part of featurePotential Pitfalls and Warnings
The Golden Rule: Never Rebase Public History
This is the most critical rule. If you have pushed commits to a shared remote branch (e.g., a branch that others have pulled from), and then you rebase those commits, you rewrite their history. When others try to pull, Git will see diverging histories, leading to confusion and potential data loss for collaborators.
Consequence: Collaborators will have to
git pull --rebase or manually fix their history, which is cumbersome and error-prone.Force Pushing (
git push -f or git push --force-with-lease)After rebasing a branch that you *have* pushed (but only if you are absolutely sure no one else has pulled it), you will need to force push to update the remote:
Bash:
git push --force-with-lease origin feature-branch--force-with-lease is safer than -f because it will only force push if the remote branch hasn't been updated by someone else in the meantime, preventing you from accidentally overwriting someone else's work.Resolving Conflicts During Rebase
Conflicts during rebase are common. When Git encounters a conflict:
1. It will pause the rebase process.
2. It will tell you which files have conflicts.
3. You need to manually resolve the conflicts in the affected files (just like a merge conflict).
4. After resolving,
git add the modified files.5. Continue the rebase:
git rebase --continue6. If you want to abort the rebase at any point:
git rebase --abortConclusion
git rebase is a powerful tool for maintaining a clean, linear, and understandable project history. While it requires careful use, especially regarding shared branches, mastering interactive rebase in particular can significantly improve the quality of your commit history, making code reviews easier and your project's timeline more coherent. Practice on private branches until you're comfortable, and always remember the golden rule: never rebase public history!