What's the most efficient way to merge chained git branches that are based on each other into m-CodePudding

I often find myself working with multiple branches, each one based on its predecessor. This allows me to break down huge work items into multiple functional changes, without waiting for each PR I create to be reviewed before I check in.

Example, say I have feature foo. I will usually have a set of branches like so:

/me/foo/part1
/me/foo/part2 (based on /me/foo/part1)
/me/foo/part3 (based on /me/foo/part2)
/me/foo/part4 (based on /me/foo/part3)

As I update Part1 (due to code reviews or merges from Master), I will "propagate" the changes each time from part 1 into part 2 by merging. This is generally a painless quick process.

My question is about the stage of "repointing" parts as I start merging branches into master.

In the example above, once Part1 is ready, it will be merged into master (painless).

However, I then need to base Part2 on master (so it can too be merged). To do this (once Part1 is merged), I will issue a merge request from master to Part2.

I want this merge to be as painless as merging Part1 into Part2 was (or even easier, as usually there are very few changes when I merge Part1 into Master, so the trees should be identical)

However, this stage specifically always comes with a ton of conflicts.

Am I missing a step that would make the "re-pointing" of Part2 into Master be easier?

CodePudding user response：

Ok.... that is starting to make sense then. If there is a squash when merging feature1, git is not really able to see that feature2's changes are only those changes that start from what you merged in feature1 already because the squash commit for feature1 is a completely separate commit from feature1 as you have it in the history of feature2 and so, when merging, it won't use feature1 (the original branch) as the last common ancestor between master and feature2 but rather the starting point of feature1 (the original branch), hence, it will consider all changes that make up feature1 and feature2 as what you are trying to merge from feature2 into master... but you have already introduced changes from feature1 into master. Bottom line: do not expect this to be a smooth merge. :-D

If that is the case, it is still manageable, you just need to work a little more to be able to get feature2 in shape after you have merged its base branch:

git rebase --onto master feature1 feature2

feature1 there is the original feature1 as it is in the history of feature2 . This way you are rebasing all revisions of feature2 onto master making sure to not bring over the original revisions of feature1 (which have been squashed... so git is not really able to see them as merged).

Squashing can make life a little miserable so you need to be careful. It's not like it can't be solved (as I have just showed)... you just need to understand what is going on to figure it out.