Rebasing a mess of inter-merged branches

Question

After asking this Creating a patch in git gives some headaches and learning how to use rebase for the first time, I realised that I should've been using it for some other things too.

There's an upstream repository which I have cloned. I have made some of my own testing and debugging configurations which I don't plan to ever push. When the upstream repository has been updated, I have always merged the changes to my "testing" branch. Now I realise that rebasing my testing branch to the newest commits in the upstream/master would keep my repository a lot cleaner.

I tried to rebase my testing branch to the newest commit on the master, but it got a number of merge conflicts - and there seems to be a lot of commits to rewrite. It will be a pain in the neck if there's going to be merge conflicts in many of those

Is there any way to just take the "state" of the testing branch, and the "state" of the master branch, and rewrite a new commit, maybe into a "testing2" branch that has all the differences?

Answer 1

To answer your last paragraph:

Is there any way to just take the "state" of the testing branch, and the "state" of the master branch, and rewrite a new commit, maybe into a "testing2" branch that has all the differences?

There, is. git merge --squash branch will perform a merge and put all changes into a single commit. You will lose all commit information including history and merge infos though, so be sure to understand the consequences. Also, having single huge commits is rarely helpful.

Using git rebase should work as well if both branches share a common ancestor. Git is smart enough to figure out which commits are already contained in master and which are not, and will accordingly linearize your history.

Answer 2

Without seeing the commit differences, I'd recommend cherry-picking. Create a new branch off the freshest upstream/master, and then cherry-pick (git cherry-pick <hash>) the commits you've made on your own branch.