Git: is it safe to rebase a branch already merged?

Question

Is it safe to rebase local (private) feature branch, if it's already merged to master, and I decide to tweak the feature later by rebasing the feature branch on the current tip of master? I know it's death sentence to rebase a shared branch, but is it safe in this case, as long as branch itself is private? As far as I can see, rebasing in this scenario will only add those diverged changes in master on top of the common history plus some local changes of the branch totally private to me. So no harm should be done, right? Is there any special scenarios, where this pattern would cause problems?

EDIT

One concern to think about is, if I perform interactive rebase on a feature branch to clean up the commit history, for example

git rebase -i HEAD~3

and this branch has already been merged to master, then both branches introduces same changes with different commits right? And this of course is not desired.

score 1 · Answer 1 · edited May 23 '17 at 12:07

So you have a feature branch that was merged to master, and then more commits were added in both master and the feature branch. That is:

      A---B---C---D---E topic
     /         \
D---E---F---G---M---X---Y master

When you rebase the feature branch on master, that will practically insert the commits that were added in master, in front of the commits that you added locally in the feature branch. Exactly as you wrote yourself. That should work fine. You will get:

      A---B---C           D'---E' topic
     /         \         /
D---E---F---G---M---X---Y master

This pattern should not cause any harm. There's just the usual risk with any rebasing, that your commits in the feature branch may conflict with the changes that were added in master. That has nothing to do with the "pattern", that's just the usual risk of any rebase and merge operation.

I'm also going to quote an addendum by @VonC:

Not only the pattern will not cause any harm, but it will help minimizing the number of commits to replay by the git rebase, while integrating the latest master commits into your feature environment, helping you to resolve conflicts locally before merging feature to master later on. (stackoverflow.com/a/804178/6309).

Not only the pattern will not cause any harm (+1), but it will help minimizing the number of commits to replay by the `git rebase`, while integrating the latest `master` commits into your `feature` environment, helping you to resolve conflicts locally *before* merging `feature` to `master` later on. (http://stackoverflow.com/a/804178/6309). — VonC, May 07 '16 at 09:30

score 0 · Answer 2 · answered May 07 '16 at 08:50

Like documentation says :

Rebase is a good way to "synchronise" by take care to save your current commit, apply commits on branch you rebase, and then apply saved commits.

Here the scenario :

      A---B---C topic
     /
D---E---F---G master

From this point, the result of either of the following commands:

git rebase master git rebase master topic would be:

              A'--B'--C' topic
             /
D---E---F---G master

Don't forget that rebase, like merge, should leads to merge conflicts, it's Git life.

Git: is it safe to rebase a branch already merged?

2 Answers2