Does git rebase affect other branches?

Does git rebase affect other branches?

Yes, git rebase can affect other branches, but only if you rebase a branch that other developers have already pulled and started working from. Rebasing a local, unshared branch has no impact on other branches in the repository.

The key to understanding this lies in how rebase works. It rewrites the commit history of a branch by moving its commits to a new base. When you run git rebase, you're essentially creating a new set of commits that replace the original ones.

---

How git rebase Can Affect Others

The main rule of thumb with git rebase is: "Don't rebase a branch that other people are working on." This is often referred to as "the golden rule of rebasing" (3).

Here's why:

1. Divergent Histories: When you rebase a shared branch, you create a new, rewritten history. Other developers who have pulled the original version of that branch will have a different history than your new one.
2. Merge Conflicts for Everyone: When those developers try to integrate their work, they won't be able to simply pull your changes. Git will see their local branch and the remote branch as having diverged, forcing them to perform a merge. This can create confusing merge conflicts for them.
3. Broken Workflows: If they try to push their changes, their push will fail because their history is different from the remote one. They would have to force-push to get their changes onto the remote, which can be dangerous and lead to lost work.

Let's illustrate with a simple scenario:

• You and a coworker, Alex, both start a new branch, feature/login, from main.
• You make some commits and push them to the remote. Alex pulls your changes.
• Later, you decide to rebase your feature/login branch onto the latest main branch to get new updates. You force-push your rebased branch.
• Now, Alex's local feature/login branch is based on the old history, while the remote feature/login has a new, rewritten history. Alex is now in a messy situation, unable to easily synchronize their work with the remote branch.

The diagram shows how the original commits (C3, C4) on the remote branch are replaced by the new, rebased commits (C3', C4'), leaving Alex's local branch with an orphaned history.

---

When Is It Safe to Rebase?

Rebasing is perfectly safe and a recommended practice when you're working on a private, local branch that hasn't been pushed to a remote repository or shared with anyone else.

Example of a safe rebase:

1. You create a new local branch, feature/refactor.
2. You make several commits.
3. You fetch the latest changes from main.
4. You rebase your feature/refactor branch onto origin/main to update it.
5. After the rebase is complete, you push your feature/refactor branch to the remote for the first time.

In this scenario, no one else has a copy of your branch's original commits, so there's no risk of a divergent history. The linear, clean history you created with the rebase will be the only version of the branch that anyone ever sees.

---

Summary

Situation	Can you rebase?	Impact on others
Local branch, not shared	Yes	None
Public/shared branch	No	Creates divergent history, causes conflicts and confusion for others
Private branch, already pushed but not worked on by others	Yes, with caution	Requires git push --force-with-lease (2), but as long as no one else has fetched it, it's generally safe

git rebase is a powerful tool for maintaining a clean, linear commit history, but its power comes with the responsibility of not affecting your collaborators' workflows. Always rebase your private work and merge shared branches (1).

---

Sources

1. Git Merge vs. Rebase
2. Git Push
3. The Golden Rule of Rebasing