Merge Master branch into feature-branch which(feature-branch) also has sub branches based on feature-branch

Question

I have a feature-branch which is from master some time back. Now, master branch has advanced and feature-branch has many sub-branches on top of it. I want to have all the new changes from master branch into my feature-branch and that should not disturb any of the existing sub-branches of feature-branch.

If I rebase my feature-branch on master branch, all the sub-branches which were on feature-branch will become stranded (based on my previous experience).

Please let me know how we can handle this.

Karimakarin

I thought about rebase --rebase-merges (https://mcmap.net/q/12419/-what-exactly-does-git-39-s-quot-rebase-preserve-merges-quot-do-and-why), but I don't think it would work in your case, if your sub-branches were not merged back. – Trellis

I see merging master into feature-branch should be good. @Trellis – Karimakarin

Answer 1

I merged master branch into my feature-branch and resolved conflicts.

git checkout master
git pull
git checkout feature-branch
git merge master

This didn't disturb any of the comment history in existing sub-branches of my feature-branch.

I did rebase the sub-branches on top of the feature-branch(with latest changes) and all looks fine.

Karimakarin

Answer 2

Let's try to answer this with a couple of general illustrations, since we don't know exactly how your particular case look like. First of all, let's agreeing on how merge and rebase differs, before looking at the case your are asking for, where multiple feature branches based on each other.

As you are probably aware merge preserves history as it happened, while rebase rewrites it. The difference can be seen in above illustration.

Now, let's try to answer your initial question with a similar illustration; where two feature branches (feature-1 & feature-2) are based on each other, and currently trails behind master.

Regardless of how you decide to integrate the changes from master into feature-1 (merge or rebase), feature-2 will be left as is (i.e. without the newly integrated changes from master into feature-1). If you then want to integrate all changes into feature-2 you are once again left with the option of merging or rebasing.

If you would decide to rebase feature-2 onto feature-1 (post the initial master integration) Git would then figure out that commits ol42g and 09qr2 are already present, and hence automatically strip those patches out from your rebased version of feature-2.

A cautionary warning: Rebasing branches that have already been published can cause headaches for your team mates, so make sure to keep a tight dialog if that would be the case. To stay on the safe side, don't rebase branches that are already publicly available.

Hopefully it should be clear now what your options are. =)

Shrew

Answer 3

I generally agree with this statement:

If I rebase my feature-branch on master branch, all the sub-branches which were on feature-branch will become stranded (based on my previous experience).

And to prevent that issue, the obvious answer is to merge the latest master into feature-branch, which BTW doesn't require having a local copy of master since you can use the remote (usually called origin):

git switch feature-branch # if not already checked out
git fetch
git merge origin/master

However, OP has added an answer as well, which contains some new information:

I did rebase the sub-branches on top of the feature-branch(with latest changes) and all looks fine.

If you are willing to rebase all of the sub-branches, then that means you can still rebase feature-branch onto master if you prefer that over merging. If you use rebase, you just need to keep track of the old commit of feature-branch before it gets rebased onto the latest master:

git switch feature-branch # if not already checked out
git branch feature-branch-old -f # -f is explained below
git fetch
git rebase origin/master
# and now for each sub-branch:
git switch sub-branch1
git rebase --onto feature-branch feature-branch-old

Note, the main difference here is for each sub-branch, instead of a basic rebase: git rebase feature-branch, you just need to a do a "fancy" rebase to change the starting point.

Once the sub-branches are all rebased you can delete branch feature-branch-old. Though, if you plan to continue to update feature-branch by rebasing onto future versions of origin/master, then you might as well keep it around until feature-branch no longer exists. If you do this, you can simply repeat the above steps as often as you need to. This the reason I used -f when creating feature-branch-old. The -f will force overwriting an existing branch if it exists, and if you repeat the above steps it will be needed.

If you generally prefer rebase over merge, I would lean towards this strategy since it's barely more work, and cleaner in the long run.

Aristocracy

Answer 4

git checkout last-sub-branch
git rebase master --update-refs

--update-refs is a feature in git (which was not available at the time when this question was asked) which will achieve exactly what is asked in the question. It will basically rebase the whole strcuture with feature-branch and its sub-branches on top of master branch with new changes.

Note: Just like a normal rebase, commit IDs in all the branches will be changed, and for every branch you'll have to do force push

Refer Working with stacked branches in Git is easier with --update-refs article for detailed examples with diagrams.

Abdel