Hacker News Reader

Looks very sensible. We tend to not have a long running dev branch, and just cut features branches off master, similar to the 'how github uses github to build github' presentation [1].

Is anyone making squashing part of their workflow? We seem to prefer just plain merges with rebase.

[1] http://zachholman.com/talk/how-github-uses-github-to-build-g...

View on HN

Instead of squashing everything into a single master commit for each bugfix (which I've seen teams do), I use a merge commit to signify a set of commits that comprise a single feature or fix. (`git merge --no-ff`)

I make use of squashing when there is a clear group of commits that all change the same few lines of code or are conceptually part of the same incremental change. But then each incremental change (from working state to newer working state) I leave as a separate commit.

We don't squash and we just use plain merges. It gives the real version of what happened. This is what I personally prefer.

Reply on news.ycombinator.com