In Git I can use an interactive rebase to re-write history, this is great because in my feature branch I made a ton of commits with partially working code as I explored differen
Vampire's answer is right, but I want to offer a different perspective. I think this is where you are getting yourself more wound up than necessary: you start with:
Lets say I want to keep commits 3, 4 and 7.
but then add:
- 1 and 2 go into 3.
- 4 stays
- 5 and 6 go into 7
But this means you want to keep (the contents of) all of 1, 2, 3, 4, 5, 6, and 7 ... just not as separate commits. The interactive rebase squash
does not mean "throw away", nor even "throw away commit message", it just means "combine". It might be better if the verb were "combine" or "meld" or "mix-in" or some such. So the sequence (pick, squash, squash) means: keep all three, while applying them in that order, then make one big commit out of them.
As already noted, once Git goes to make one big commit out of them, Git gives you another chance to edit the three combined commit messages into one big commit message.
When the rebase is done, you haven't kept any of the original commits. Instead, you have made new commits. It doesn't matter precisely how your new first commit was assembled from parts, only what the final source was, and what you put in the one big commit message.