Rebasing Foundations

Rebasing is a powerful and often misunderstood feature in Git. While both merging and rebasing are designed to integrate changes from one branch into another, they achieve this through fundamentally different mechanisms.

In simple terms, rebasing is the process of moving or combining a sequence of commits to a new base commit. From a content perspective, rebasing is like saying, "I want to base my changes on the latest work others have done."

---

1. The Core Mechanism: Moving the Base

Imagine you branched off main at commit B to work on a feature. While you were busy creating commits C and D, your teammates pushed commits E and F to main. Your histories have now diverged.

Diverged State (Before Rebasing)

When you rebase, Git performs the following steps:

1. It identifies the common ancestor of your branch and the target branch (Commit B).
2. It temporarily saves your commits (C and D) in a temporary area.
3. It resets your feature branch to the tip of the target branch (Commit F).
4. It "re-plays" your saved commits (C and D) one by one onto the new base (F).

Rebased State (After Rebasing)

Notice that your commits are now C' and D'. They have new SHA-1 hashes because they are entirely new commit objects with a different parent.

---

2. The Golden Rule of Rebasing

The most important rule to remember is: Never rebase commits that you have pushed to a shared repository.

Because rebasing rewrites history, it creates a serious problem for anyone else working on the same branch. If you push a rebased branch, you are effectively deleting the original commits and replacing them with new ones. Your teammates' local repositories will still have the old commits, leading to a confusing and broken history when they try to sync.

• Rebase locally: Use it to clean up your own work before merging it into a shared branch.
• Merge into public: Use a standard merge when integrating your finished work into a branch that others are using.

---

3. Practical Workflow: Staying Up-to-Date

In a fast-moving project, your feature branch can quickly fall behind main. Instead of merging main into your feature branch (which creates a messy "merge commit"), you can rebase.

# Switch to your feature branch
git switch feature-x

# Rebase your work onto the latest main
git rebase main

Resolving Conflicts During Rebase

If Git finds a conflict while re-playing a commit, it will pause. You must:

1. Open the file and fix the conflict.
2. Stage the fix: git add <file>.
3. DO NOT COMMIT. Instead, run: git rebase --continue.

If you get stuck or change your mind, you can always go back to safety with:

git rebase --abort

---

4. Why Teams Prefer Rebasing

Modern engineering teams often favor rebasing for several reasons:

1. Linear History: It creates a straight line of commits, making it much easier to use tools like git log and git bisect.
2. Context: It keeps related changes together. Instead of scattered merge commits, you see a logical sequence of features.
3. Simplicity: It avoids the "diamond-shaped" history graphs that occur with frequent merging, which can become unreadable in large projects.

In the next chapter, we will look at Interactive Rebase, the ultimate tool for polishing your local commit history before sharing it with the world.