Hacker News Reader

I disagree with your disagreement. Rebasing/squashing can really help clean up the development history and actually make it a ton more useful as a historical reference.

Like all things in programming, discretion is key and obviously it can be overdone, but anecdotally, I've found that it makes the history so much more useful to lump related changesets together.

In short, categoricals like "don't do it, you'll lose history" don't really hold much water for me. Of course it can be over done. But done right, it really is a great feature of git and a god-send on larger projects (check out the actual git source log for an example).

I would have to second this. I will almost always squash (or split) commits in a branch before review to have it merged back into the master branch. I try to have each commit do a specific individual task. While adding docs to the api could be a separate function (just because you did it last) I would rather have that squashed so in two years when you are looking at the new function you see the api docs that go with it. This doesn't mean everything should be in 1 commit and it also doesn't mean 30 commits. Common sense plays a big role here.

I'm with you 100%. Before publishing my changes I always rebase -i origin/master and edit the history, keeping in mind consistency, usefulness in the history, and the poor guy who has to review my changes before they hit mainline. (we use gerrit) Thinking of it in terms of code review is actually very helpful; I find it leads to very clear, self-contained commits with good comments.

I'm with you. One of the great things about git and its ability to 1) easily branch and 2) rewrite history is that I can go down a certain path in a feature branch, realize I need to approach it differently, make mistakes, fix those mistakes but still commit a clean patch for public consumption.

I agree with you, at least assuming it is a big feature. Squashing 30 commits into 1 loses a lot of information.

The best approach I have found is to use merge --no-ff to merge the feature branch to the master branch. This lets you both keep the history and group the feature's commits together.

I think squashing is useful for a feature branch whose history looks like:

  1d9322f Added model & migration for feature x
  3fa93f9 Unit tests for feature x
  38ce239 Fixed intermittent failure in test_feature_x_foo
  6728eca Added view and css for feature x
  8fed23d Added missing background image for feature x
  392ea84 Refactored feature x controller to handle foobaz

Instead of littering the master branch with those 6 commits, wouldn't it be nice to have just:

  84fac31 Added feature x with tests and support for foobaz

This has the advantage of

1) Less noise in history, so easier to page through and see what has happened

2) The feature is in a single commit, so I can more easily cherry-pick it into a release branch if I need it

3) Impressing your co-developers as it looks like you got it right the first time

I agree that squashing all of the commits for a feature together loses a lot of information. I usually follow a workflow similar to the one described, except without this squashing step. That is:

    1. Branch off of master to work on the feature.
    2. Work, work, work, commit, commit, commit
    3. Pull down any updates to master
    4. Rebase the feature on master without squashing the commits
    5. Merge the feature branch back to master
    6. Push up to the shared repository

Rebasing is not the problem, squashing is[1]. I never understood that. To me, it suggests the person does not understand branch merges. You should either:

A. Rebase on top of master, keeping all commits; or

B. Merge the branch, keeping branch history.

[1] Obviously squashing has good uses, too, within the branch. Maybe you want to squash together all commits for a particular feature's implementation (while still keeping the specs for same in a separate commit, hopefully).

Though not explicitly written in the article, it seemed to me that JJ was recommending this approach for dealing with short-lived 'topic' branches like bug fixes and small features. At least, that was the nature of each example branch he gave.

I agree with you that if you have a longer-lived branch that's shared among repositories, you'll want to see that merge in the history and optionally squash some of the commits as needed. For short lived topic branches, I often like to squash down to a single commit.

I have found squashing useful for merging a bug fix branch. Half of a bug fix does nobody any good.

You could squash parts of a single bugfix, sure, if you end up with multiple commits. Still, though, I would leave the spec you wrote (you write tests or specs for bugs you find, right? Right?:) in a separate commit - in case you for example need to revert the fix at some point, or someone else just wants to cherry-pick the spec.