问题
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 different refactors and ways of getting it done.
I'd like to squash a lot of the commits together before rebasing or merging the branch onto master.
Some made up commits in order from first (top) to bottom (last)
1. Initial commit on feature branch "Automatic coffee maker UI"
2. Add hot chocolate as product
3. Add tea as product. Products are now generic
4. Create in memory data store for adapter tests
5. Cry because I can't get entity framework to create a composite key. Integration tests broken.
6. Implemented composite key!!
7. All tests green and feature done!
Lets say I want to keep commits 3, 4 and 7.
Using rebase I want to "squash" commits
- 1 and 2 go into 3.
- 4 stays
- 5 and 6 go into 7
Ideally in the interactive rebase I would do
1. squash
2. squash
3. pick (contains the work of 1 & 2)
4. pick
5. squash
6. squash
7. pick (contains the work of 5 & 6)
But that is backwards because squash merges a commit with its previous commit. I can't figure out how to make it squash forward.
Am I being difficult, and should I accept that won't work (I'd rather get it working), or is there a way to accomplish this?
I'm invoking this command with
git checkout My-feature-branch
git rebase master -i
Then I'm editing the list of commits that come up, and trying to finish it by saving the file and editing the editor, which typically works for me.
回答1:
You either need to also reorder the commits so the to-be-kept commit comes before the to-be-squashed commits if this is feasible.
If this is not feasible, because you then would get conflicts you don't want to resolve, just make it
1. pick
2. squash
3. squash
4. pick
5. pick
6. squash
7. squash
When the squashes are done, you can edit the commit message to contain the message you like the final commits to have. Easy as pie. :-)
You might even be able to do
1. pick
2. fixup
3. squash
4. pick
5. pick
6. fixup
7. squash
Then I think there should only once the commit message editor being fired up, as with fixup the previous commit message is simply taken without launching the editor.
On squash when the commit message editor fires, you also get both commit messages, the one from the to-be-squashed-into and the to-be-squashed commit, so you then can simply delete the commit message you don't want to keep.
回答2:
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.
回答3:
What you want is:
1. pick
2. squash
3. fixup
4. pick
5. squash
6. squash
7. fixup
Then when the new combined commits come up in the editor delete the lines for the picked commits and leave the fixups. The resulting feature-patches should have the commit message from the last commit in the series that way.
来源：https://stackoverflow.com/questions/44210747/git-interactive-rebase-squash-into-next-commit