Mastering [ICODE]git rebase[/ICODE] for a Pristine Commit History

git rebase is a powerful Git command that allows you to rewrite commit history. While git merge is often used to integrate changes from one branch into another, git rebase provides a different, often cleaner, approach by moving or combining a sequence of commits to a new base commit. Understanding rebase is crucial for maintaining a clean, linear, and understandable project history, especially in collaborative environments.

git merge vs. git rebase: A Fundamental Difference

Before diving into rebase, it's helpful to understand its distinction from git merge.

• git merge: This command integrates changes by creating a new "merge commit." This merge commit has two parent commits, preserving the exact history of how branches diverged and then converged. It's a non-destructive operation, as it doesn't rewrite existing commits. The history can look like a graph with multiple branches intertwining.

• git rebase: This command effectively "replays" your commits from one branch onto another. Instead of creating a merge commit, rebase takes your commits, copies them, and places them on top of the target branch's latest commit. This results in a linear history, making it appear as if you started your work from the latest point of the target branch. It rewrites history, meaning the commit hashes change.

How git rebase Works

When you run git rebase <base_branch> from your feature branch, Git performs the following steps:

1. It finds the common ancestor between your current branch and the <base_branch>.
2. It takes all the commits on your current branch that are *after* this common ancestor and temporarily stores them.
3. It resets your current branch's head to the same commit as the <base_branch>.
4. It then "replays" your stored commits, one by one, on top of the <base_branch>.
5. For each replayed commit, if there are conflicts, Git will pause and prompt you to resolve them.

Basic git rebase Usage

Let's say you're on a feature branch and want to rebase it onto main:


If conflicts occur during the rebase process:

1. Git will tell you which files have conflicts.
2. Manually edit the conflicted files to resolve the differences.
3. Stage the resolved files: git add <conflicted_file>
4. Continue the rebase: git rebase --continue
5. If you want to stop the rebase process at any point: git rebase --abort

Interactive Rebase (git rebase -i)

This is where rebase truly shines. Interactive rebase allows you to modify individual commits in a sequence. You can squash, reword, edit, or even drop commits.

To start an interactive rebase, you specify how far back you want to go. For example, to rebase the last 3 commits:


Git will open your default text editor with a list of commits and instructions:


You can change pick to any of the commands:

• pick: Use the commit as is.
• reword: Use the commit, but stop to edit its message.
• edit: Use the commit, but stop for you to amend it (e.g., add more changes, split it).
• squash: Combine this commit with the *previous* one. Git will then open an editor for you to combine their commit messages.
• fixup: Like squash, but it discards this commit's message, keeping only the previous one's. Useful for small fixes that logically belong to a prior commit.
• drop: Remove the commit entirely.

After making your changes in the editor and saving, Git will execute the commands in order. If you used edit or reword, Git will pause and prompt you to finish the action.

Warnings and Best Practices

1. NEVER REBASE PUBLIC HISTORY: This is the golden rule. If commits have already been pushed to a remote repository and other developers have pulled them, rebasing those commits will rewrite their history. When you then force push (git push --force or git push --force-with-lease), it will cause significant problems for anyone who has based their work on the old history, leading to lost work or complex conflict resolution. Only rebase commits that exist *only* on your local machine or a branch that no one else has pulled from.
* If you *must* rebase a public branch (e.g., you're the only one working on it, or you've coordinated with your team), use git push --force-with-lease instead of git push --force. --force-with-lease is safer as it won't overwrite others' work if the remote branch has new commits you haven't pulled yet.

2. Rebase Frequently on Feature Branches: If you're working on a long-lived feature branch, rebase it onto main regularly. This keeps your branch up-to-date with main, making integration easier and reducing the chance of large, complex conflicts later.

3. Commit Often, Squash Later: Don't be afraid to commit small, incremental changes. You can always use git rebase -i to squash them into logical, larger commits before merging into main. This allows for a clean, understandable history without forcing you to craft perfect commits every time.

4. Always Pull Before Rebase: Before rebasing your branch onto a target branch (like main), ensure your local copy of the target branch is up-to-date: git checkout main && git pull origin main.

git rebase is an indispensable tool for maintaining a clean and linear project history. While it has a steeper learning curve than git merge and carries the risk of rewriting history, its benefits in terms of project clarity and simplified debugging are immense when used judiciously and correctly. Practice on throwaway branches until you're comfortable!