You're looking for the squash feature of an interactive rebase:
Use git rebase -i HEAD~2 to start an interactive rebase. In the opening editor, all commits that are part of the rebase are listed. In this case, since we provided the HEAD~2 argument to the rebase call, we see two commits, each prefixed by pick. Not changing anything would lead rebase to pick, i.e. apply both commits, and nothing would be different. Instead, what you want to do is to pick only one commit, while squashing the other one. This way, you squash the second commit into the first one, resulting in a single commit. When you safe and exit now, git will promt you for a new commit message, and voilà: a new commit containing changes from both of the older commits.
As always when messing with history (as squashing different commits into a new one definitely is), you should only perform such operations on commits that you are sure nobody else based their work on.
No matter the approach, before anything else make sure the working copy is clean. Use git status to find out. If there are uncommitted changes either save them in a stash (git stash or commit them on a temporary branch.
Run git branch backup to create a backup branch on the current commit.
It is not really needed (the same result can be achieved using the reflog or by writing down the hash of the current commit) but it is the easiest way to restore the current status if something goes wrong.
Run git reset --soft HEAD~2.
This moves HEAD two commits in the past (on commit e8de117) without changing the working tree or the index. The index and the working tree look now like they were just before you created the commit 6aa74e4. All the files changed in the last two commits will be already added to the index. Because HEAD is on e8de117, the next commit will be created on top of e8de117 (it will "replace" commits 6aa74e4 and 77c15d6).
Run git commit. You'll have to enter a new commit message.
If the result doesn't look like you expected (git diff backup should not report any difference) or if you have changed your mind, run git reset --hard backup to go back where you started from (actually, right after step #2).
If you are pleased with the output then remove the backup branch created at step 2 (git branch -D backup).
You're looking for the
squash
feature of an interactiverebase
:Use
git rebase -i HEAD~2
to start an interactive rebase. In the opening editor, all commits that are part of the rebase are listed. In this case, since we provided theHEAD~2
argument to therebase
call, we see two commits, each prefixed bypick
. Not changing anything would lead rebase topick
, i.e. apply both commits, and nothing would be different. Instead, what you want to do is topick
only one commit, whilesquash
ing the other one. This way, you squash the second commit into the first one, resulting in a single commit. When you safe and exit now, git will promt you for a new commit message, and voilà: a new commit containing changes from both of the older commits.See here for detailed instructions.
As always when messing with history (as squashing different commits into a new one definitely is), you should only perform such operations on commits that you are sure nobody else based their work on.
There are many ways to do it (using
rebase
orreset
).The approach using
git reset
:git status
to find out. If there are uncommitted changes either save them in a stash (git stash
or commit them on a temporary branch.git branch backup
to create a backup branch on the current commit.It is not really needed (the same result can be achieved using the
reflog
or by writing down the hash of the current commit) but it is the easiest way to restore the current status if something goes wrong.git reset --soft HEAD~2
.This moves
HEAD
two commits in the past (on commite8de117
) without changing the working tree or the index. The index and the working tree look now like they were just before you created the commit6aa74e4
. All the files changed in the last two commits will be already added to the index. BecauseHEAD
is one8de117
, the next commit will be created on top ofe8de117
(it will "replace" commits6aa74e4
and77c15d6
).git commit
. You'll have to enter a new commit message.git diff backup
should not report any difference) or if you have changed your mind, rungit reset --hard backup
to go back where you started from (actually, right after step #2).backup
branch created at step 2 (git branch -D backup
).