I've taken an example git repository so we can walk through how we'd do this with rebase and merge.
We can actually see the merge of the
feature/another-talk branch is already complete since it's cleanly merged into
main with no intermediate commits to main - there was no need to rebase and merge, so it's just the other two branches we need to worry about.
Now, I've created a new branch from the latest
main and faded out our existing
If you've ever done a cherry-pick before to move a commit from one branch to another, a rebase is like an extreme version of that! When told to rebase, git will cherry-pick each commit in a branch in turn and add it to a new branch at the point requested (in this case, a later version of the same
Here I've "cherry-picked" the "Write talk" commit and put it onto our new branch.
Then we repeat that for all the other commits needed (including "fix typos" in that other branch), adding them in order and fixing any merge conflicts that may come about for each one.
And that's actually the rebase out the way! We've "cherry picked" each commit and resolved any merges, but in a more automated way than actually doing loads of cherry-picks.
Now it's time to merge
That old branch doesn't need to be there anymore - it doesn't actually exist locally, so we can hide that.
And then all we have to do is rebase and merge our final branch,
To give us this!
Each feature makes a neat "D" shape with the
develop branch, with no crossovers. As you can see, when compared to a traditional merge process shown below this method removes the muddle of crisscrossing merges, while maintaining the whole branch structure and all the detail in every commit.