Hacker News Reader

Comment by orbitur | Hacker News Reader

Wow, the first thing I do when creating a new repo is disable fast-forwarding, especially for large teams.

The merge commit is the quickest way to see all the changes that came in from a branch, and if you do branching right, all the changes related to a particular feature by one developer.

Also, merge commits are much easier to roll back, no matter how rarely you need it.

View on HN

Another option, used by large teams at Facebook, is to only use fast-forwarding but squashes all branch commits. You can still roll-back a merge, but your master's revision history is still linear (for what that's worth).

Yes this is what I advocate doing as well in my post above.

This is how I prefer to handle PRs, too. `git merge --squash pr-branch`. Prevents the history from turning into an indecipherable tangle of branches, and prevents tons of "fixing typo," "code review feedback," "more code review feedback," "adding back file" kinds of commits from taking over the history.

We are on GH, it's quite annoying that they provide 0 support for rebase/squash style PR application. http://stackoverflow.com/q/27974175/1366219

You can rebase commits in your feature branch as well and clean up the history. Having separate and small commits also helps in blaming and looking at the history do figure out why a certain change is in there.

If you squash all the commits you probably should summarize all the commits into that single commit message which is also work if done properly.

In the end it's preference and how your developers create commits and documment them.

Reply on news.ycombinator.com