Understanding Git Rebase

In the world of version control, Git rebase stands as one of the most powerful yet often misunderstood tools. Especially for developers like us, working on collaborative projects, mastering git rebase can transform how we manage code history, resolve conflicts, and maintain clean, linear commit histories.

However, it's equally known for being dangerous when used incorrectly, as it involves rewriting history. This guide explores all facets of git rebase, including real-world scenarios, practical command-line examples, and why it can be both powerful and hazardous.

What is Git Rebase?

Git rebase allows you to move or "reapply" commits from one branch on top of another. This operation rewrites the commit history in the process. When working with multiple collaborators, rebase offers a way to synchronize the local work with the upstream repository cleanly.

In a typical git pull operation, the default merge strategy creates a new "merge commit" to combine changes. In contrast, rebase moves your changes onto the tip of another branch, creating a linear history and avoiding merge commits.

Key Points:

• Rewriting History: Rebase changes the commit history.
• Commit Cherry-picking: It picks commits from one branch and replays them on another.
• Linear History: This is the primary advantage—simplifying the history by removing unnecessary merge commits.

Why is it everyone think Git Rebase is Dangerous?

The primary danger of git rebase comes from the fact that it rewrites commit history. Once history is rewritten and pushed to a shared repository, it can lead to confusion, lost commits, or merge conflicts for others working on the same branch.

A few important points:

Changes Commit IDs: Each commit gets a new hash, so any reference to old commit IDs will be broken.

Pushing After Rebase Can Break Shared Repos: If you push after rebasing a branch that others have already pulled, their version of the branch will conflict with the rewritten history.

Losing Uncommitted Work: If conflicts are not properly resolved during rebasing, uncommitted work might be lost.

To safely use git rebase, follow this golden rule:

Never rebase commits that have been pushed to a shared repository.

Rebase vs. Merge: Key Differences

While both rebase and merge aim to combine changes from different branches, but they take radically different approaches:

Git Merge

Commit History: Creates a merge commit, keeps all history.

Workflow: No changes to existing commits

Merge Commits: Creates merge commits

Usage: Suitable for preserving full history

Git Rebase

Commit History: Rewrites history by moving commits

Workflow: Re-applies commits on top of the new branch

Merge Commits: Does not create merge commits

Usage: Ideal for linear, clean history.

Example:

Let's say you have the following commit history:

  A---B---C feature-branch
 /
D---E---F master

Using git merge feature-branch from master will result in:

  A---B---C   feature-branch
 /         \
D---E---F---M   merge commit master

Using git rebase master from feature-branch will reapply the feature branch commits on top of master:

D---E---F---A---B---C rebased feature-branch

History Rewrite: What Does It Mean?

When we talk about rewriting history in Git, we mean changing the commit graph or altering the details of past commits (like commit IDs, messages, or ordering). Rebase changes the parent commit of each commit in the rebased branch. This makes it appear as if the commits were made directly on top of the target branch.

Interactive Rebase: The Power at Your Fingertips

Interactive rebase (git rebase -i) is one of the most powerful features in Git. It allows you to rewrite commits in a detailed, customizable way. You can:

Squash commits: Combine multiple commits into one.

Reword commit messages: Edit the message of specific commits.

Drop commits: Remove unnecessary commits from the history.

Basic Rebase Workflow

Let's consider a scenario where you're working on a feature-branch and the master branch has progressed with new commits. You want to incorporate the latest changes from master into your feature-branch while keeping a linear history.

Steps:

Fetch latest changes from the remote:

git fetch origin

Switch to feature-branch:

git checkout feature-branch

Rebase on top of master:

git rebase origin/master

This will move all your commits in feature-branch on top of the latest master branch commits.

Complex Rebase Workflow

Rebase Conflicts and How to Resolve Them

Rebase conflicts are inevitable when your branch modifies the same files as the branch you’re rebasing onto.

When rebasing feature-branch onto master, Git may detect that both branches modified the same line in file foo.txt.

Git will stop at the conflicting commit and mark the file as conflicted.

Open the conflicted file and manually resolve the differences.

After resolving, run:

git add foo.txt
git rebase --continue

Rebase with Multiple Branches

In a scenario with more than two branches, rebasing becomes more complex but follows the same principles.

git checkout feature-branch
git rebase release

Your commits will be replayed on top of release, ensuring your changes are up-to-date with the release branch while still staying synced with develop.

git rebase --abort

Rebase Best Practices

Rebase Locally, Merge Remotely: Rebase is perfect for keeping your local history clean, but when pushing changes, consider using merge to avoid overwriting shared history.

Rebase Before Push: Always rebase your feature branch onto the latest master before pushing to avoid merge commits.

Interactive Rebase for History Cleanup: Use git rebase -i to curate your commit history before making your changes public.

Conclusion

Git rebase is an incredibly powerful tool, but it should be used with caution. Its ability to rewrite history makes it ideal for keeping commit histories clean, but also risky when used on shared branches. By mastering rebase commands and understanding when to apply them, can streamline Git workflows while avoiding common pitfalls.