Trimming Git Commits/Squashing Git History

Question

I check my code into a Git branch every few minutes or so, and the comments end up being things like "Everything broken starting again" and other absurdities.

Then every few minutes/hours/days I do a serious commit with a real comment like, "Fixed bug #22.55, 3rd time." How can I separate these two concepts? I would like to be able to remove all my frequent-commits and just leave the serious ones.

Answer 1

Using Squash Instead

Recently, I've been working in another branch and using squash. The other branch is called temp, and then I use git merge temp --squash to bring it into the real branch that gets pushed to the server.

Workflow is something like this, assuming I'm working in Ticket65252:

git branch -d temp #remove old temp bbranch
git checkout -b temp
# work work work, committing all the way
git checkout Ticket65252
git merge temp --squash
git commit -m "Some message here"

Advantages over using rebase? Way less complicated.

Advantages over using reset --hard and then reset --soft? Less confusing and slightly less error prone.

Answer 2

Edited answer with now (in the second half of this entry) the new Git1.7 fixup! action and --autosquash option for quick commit reordering and message editing.

---

First, the classic squashing process, as done before Git1.7.
(Git1.7 has the same process, only made faster by the possibility of automatic commit reordering as opposed to manual reordering, and by cleaner squashing messages)

I would like to be able to remove all my frequent-checkins and just leave the serious ones.

This is called squashing commits.
You have some good example of "comit cleaning" in this Git ready article:
(Note: the rebase interactive feature came along since September 2007, and allows for squashing or splitting or removing or reordering commits: see also the GitPro page)

A word of caution: Only do this on commits that haven’t been pushed an external repository. If others have based work off of the commits that you’re going to delete, plenty of conflicts can occur. Just don’t rewrite your history if it’s been shared with others.

alt text http://www.gitready.com/images/squash1.png

The last 4 commits would be much happier if they were wrapped up together

$ git rebase -i HEAD~4

pick 01d1124 Adding license
pick 6340aaa Moving license into its own file
pick ebfd367 Jekyll has become self-aware.
pick 30e0ccb Changed the tagline in the binary, too.

# Rebase 60709da..30e0ccb onto 60709da
#
# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

rebase using the last four commits from where the HEAD is with HEAD~4.
We’re just going to squash everything into one commit.
So, changing the first four lines of the file to this will do the trick:

pick 01d1124 Adding license
squash 6340aaa Moving license into its own file
squash ebfd367 Jekyll has become self-aware.
squash 30e0ccb Changed the tagline in the binary, too.

Basically this tells Git to combine all four commits into the the first commit in the list. Once this is done and saved, another editor pops up with the following:

# This is a combination of 4 commits.
# The first commit's message is:
Adding license

# This is the 2nd commit message:

Moving license into its own file

# This is the 3rd commit message:

Jekyll has become self-aware.

# This is the 4th commit message:

Changed the tagline in the binary, too.

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# Explicit paths specified without -i nor -o; assuming --only paths...
# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   LICENSE
#   modified:   README.textile
#   modified:   Rakefile
#   modified:   bin/jekyll
#

Since we’re combining so many commits, Git allows you to modify the new commit’s message based on the rest of the commits involved in the process. Edit the message as you see fit, then save and quit.
Once that’s done, your commits have been successfully squashed!

Created commit 0fc4eea: Creating license file, and making jekyll self-aware.
 4 files changed, 27 insertions(+), 30 deletions(-)
  create mode 100644 LICENSE
    Successfully rebased and updated refs/heads/master.

And if we look at the history again…

alt text http://www.gitready.com/images/squash2.png

---

Note: for "commit squashing" purposes, Git1.7 (February 2010) has introduced 2 new elements (as mentioned by Dustin in the comment):

• "git rebase -i" learned new action "fixup" that squashes the change but does not affect existing log message.
• "git rebase -i" also learned --autosquash option that is useful together with the new "fixup" action.

Both (fixup action and --autosquash option) are illustrated in this Thechnosorcery Networks blog entry. Those features have been cooking since last June 2009 and debated further last December.

The fixup action or directive is for squashing a commit you would have manually reordered in the commit edit list of a rebase --interactive, while ignoring the second commit message, which will make the message edition step faster (you can just save it: the squashed commit will have the first commit message only)
The resulting commit message will only be the first commit one.

  # s, squash = use commit, but meld into previous commit
  # f, fixup = like "squash", but discard this commit's log message

The --autosquash option is about making the commit reordering process automatically for you:

If you know what commit you want to squash something in to you can commit it with a message of “squash! $other_commit_subject”. Then if you run @git rebase --interactive --autosquash commitish@, the line will automatically be set as squash, and placed below the commit with the subject of $other_commit_subject.

(Actually, the squash! can only use the beginning of another commit message)

$ vim Foo.txt
$ git commit -am "Change all the 'Bar's to 'Foo's"
[topic 8374d8e] Change all the 'Bar's to 'Foo's
 1 files changed, 2 insertions(+), 2 deletions(-)
$ vim Bar.txt
$ git commit -am "Change all the 'Foo's to 'Bar's"
[topic 2d12ce8] Change all the 'Foo's to 'Bar's
 1 files changed, 1 insertions(+), 1 deletions(-)

$ vim Foo.txt
$ git commit -am "squash! Change all the 'Bar's"
[topic 259a7e6] squash! Change all the 'Bar's
 1 files changed, 2 insertions(+), 1 deletions(-)

See? Here the third commit uses only the beginning of the first commit message.
A rebase --interactive --autosquash will move the squashed commit below the relevant one:

pick 8374d8e Change all the 'Bar's to 'Foo's
squash 259a7e6 squash! Change all the 'Bar's
pick 2d12ce8 Change all the 'Foo's to 'Bar's

The message edition would be:

# This is a combination of 2 commits.
# The first commit's message is:

Change all the 'Bar's to 'Foo's

# This is the 2nd commit message:

squash! Change all the 'Bar's

Meaning by default you would keep the squashing operation recorded in the commit message.
But with the fixup! directive, you could keep that squashing "invisible" in the commit message, while still benefiting from the automatic commit reordering with the --autosquash option (and the fact that your second commit message is based on the first commit you want to be squashed with).

pick 8374d8e Change all the 'Bar's to 'Foo's
fixup cfc6e54 fixup! Change all the 'Bar's
pick 2d12ce8 Change all the 'Foo's to 'Bar's

The message by default will be:

# This is a combination of 2 commits.
# The first commit's message is:

Change all the 'Bar's to 'Foo's

# The 2nd commit message will be skipped:

#    fixup! Change all the 'Bar's

Notice that the fixup! commit’s message is already commented out.
You can just save out the message as-is, and your original commit message will be kept.
Very handy for including changes when you realize that you forgot to add part of an earlier commit.

Now if you want to fixup or squash based on the previous commit you just did, Jacob Helwig (the author of the Technosorcery Networks blog entry) recommends the following aliases:

[alias]
    fixup = !sh -c 'git commit -m \"fixup! $(git log -1 --format='\\''%s'\\'' $@)\"' -
    squash = !sh -c 'git commit -m \"squash! $(git log -1 --format='\\''%s'\\'' $@)\"' -

And for doing a rebase interactive which will always benefit from the automatic reordering of commits meant to be squashed:

[alias]
    ri = rebase --interactive --autosquash

---

Update for Git 2.18 (Q2 2018): "git rebase -i" sometimes left intermediate "# This is a combination of N commits" message meant for the human consumption inside an editor in the final result in certain corner cases, which has been fixed.

See commit 15ef693, commit dc4b5bc, commit e12a7ef, commit d5bc6f2 (27 Apr 2018) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit 4a3bf32, 23 May 2018)}

rebase --skip: clean up commit message after a failed fixup/squash

During a series of fixup/squash commands, the interactive rebase builds up a commit message with comments. This will be presented to the user in the editor if at least one of those commands was a squash.

In any case, the commit message will be cleaned up eventually, removing all those intermediate comments, in the final step of such a fixup/squash chain.

However, if the last fixup/squash command in such a chain fails with merge conflicts, and if the user then decides to skip it (or resolve it to a clean worktree and then continue the rebase), the current code fails to clean up the commit message.

This commit fixes that behavior.

The fix is quite a bit more involved than meets the eye because it is not only about the question whether we are git rebase --skiping a fixup or squash. It is also about removing the skipped fixup/squash's commit message from the accumulated commit message. And it is also about the question whether we should let the user edit the final commit message or not ("Was there a squash in the chain that was not skipped?").

For example, in this case we will want to fix the commit message, but not open it in an editor:

pick  <- succeeds
fixup   <- succeeds
squash  <- fails, will be skipped

This is where the newly-introduced current-fixups file comes in real handy. A quick look and we can determine whether there was a non-skipped squash. We only need to make sure to keep it up to date with respect to skipped fixup/squash commands. As a bonus, we can even avoid committing unnecessarily, e.g. when there was only one fixup, and it failed, and was skipped.

To fix only the bug where the final commit message was not cleaned up properly, but without fixing the rest, would have been more complicated than fixing it all in one go, hence this commit lumps together more than a single concern.

---

Git 2.19 (Q3 2018) fixes a bug: When "git rebase -i" is told to squash two or more commits into one, it labeled the log message for each commit with its number.
It correctly called the first one "1st commit", but the next one was "commit #1", which was off-by-one(!).

See commit dd2e36e (15 Aug 2018) by Phillip Wood (phillipwood).
^{(Merged by Junio C Hamano -- gitster -- in commit 36fd1e8, 20 Aug 2018)}

rebase -i: fix numbering in squash message

Commit e12a7ef ("rebase -i: Handle "combination of <n> commits" with GETTEXT_POISON", 2018-04-27, Git 2.18) changed the way that individual commit messages are labelled when squashing commits together.
In doing so a regression was introduced where the numbering of the messages is off by one. This commit fixes that and adds a test for the numbering.

Answer 3

Use git rebase -i to pick and squash your commits together.

Answer 4

Using Soft Reset Instead of Rebase to Squash GIT History

I think the length of VonC's answers speaks volumes -- literally -- about how complicated git rebase is. This is my extension of another answer to a question of mine.

1. You have a branch ticket-201 that you branched from master. You want to pretend that all the commits from ticket-201 never happened, but that you did all the work in one shot.
2. Soft reset to the branch point using git reset --soft hash where hash should be a commit hash that is in ticket-201's log.
3. Commit your changes using add then commit. Now the branch history will only have the first commit and the new one with the new stuff.

Making Up Histories From Arbitrary Commits in Different Branches

Using resets you can rewrite the history as you see fit, though your edits will lose the charm of having the right timestamp. Assuming you don't care about that (the times/dates on your files will be enough, perhaps?), or if you want to fiddle with the commits as you go, you can follow these steps:

1. Checkout a new branch at commit0 (pretend that's a hash): git checkout -b new-history commit0
2. Now you can get the files from commit5: git reset --hard commit5
3. Switch back to your index point: git reset --soft commit0
4. Commit and this will be the second commit in the branch.

This idea is simple, effective and flexible.