Merging a branch of a branch after first branch is squashed when merged to master

A little bit about why this happens:

I'll let O be "original master" and FB be "new master", after a feature branch has been merged in:

Say feature_branch looks like:

O - A - B - C 

dependent_feature has a few extra commits on top of that:

O - A - B - C - D - E - F

You merge your original feature branch into master and squash it down, giving you:

O - FB

Now, when you try to rebase the dependent branch, git is going to try to figure out the common ancestor between those branches. While it originally would have been C, if you had not squashed the commits down, git instead finds O as the common ancestor. As a result, git is trying to replay A, B, and C which are already contained in FB, and you're going to get a bunch of conflicts.

For this reason, you can't really rely on a typical rebase command, and you have to be more explicit about it by supplying the --onto parameter:

git rebase --onto master HEAD~3  # instruct git to replay only the last                                 # 3 commits, D E and F, onto master.

Modify the HEAD~3 parameter as necessary for your branches, and you shouldn't have to deal with any redundant conflict resolution.

Some alternate syntax, if you don't like specifying ranges and you haven't deleted your original feature branch yet:

git rebase --onto master feature_branch dependent_feature                                 # replay all commits, starting at feature_branch                                 # exclusive, through dependent_feature inclusive                                  # onto master

In this particular case it seems you "know" that only the squashed work of the branch you originally worked on has been put into master.

So you can happily merge by keeping your changes every time when there is a conflict. There is an option for that:

git merge -Xours master

See https://git-scm.com/docs/git-rebase for details more details.

I heartily disagree with the "mash every feature development down into a single commit" policy, but it's their call...

I'd keep the branches as-is, and create a mashed up commit just for publication, in a special branch. Being able to follow the development step by step is valuable, even if management doesn't believe in it. Mark the places of squashes by tags in the "real" branches, you could also add between-squash tags with messages pointing back to the real commits.