Hacker News Reader

Comment by TekMol | Hacker News Reader

    We prefer patch-based workflow.
    It makes Git history pretty.

What is wrong with the feature branch approach? Before you merge a feature branch, you can squeeze all its commits into one. That leads to a pretty history too.

View on HN

This is basically how you use Phabricator locally. Phabricator looks at patches to do code review, but the "arc land" CLI command takes your feature branch, squashes the commits, rebases onto master, and pushes that. So local development can use feature branches and the main repo has a normal git history. (Github added support for "squash and merge" maybe a year or so ago; same idea)

That's basically the same thing, just with less bells and whistles.

> Before you merge a feature branch, you can squeeze all its commits into one. That leads to a pretty history too.

With Github, you'll end up with a history like:

    Implement feature A
    Merge #1 Implement feature A
    Implement feature B
    Merge #2 Implement feature B
    ...

you basically end up with twice as many commits than you would otherwise. The other problem is that each commit ends up being rather big and the commit message is a combination of all the commits that were squashed, including ones that don't really contain any useful information (e.g., "Addressing comments").

A big commit is harder to revert (without encountering conflicts).

Use squash and merge instead. It's built right into GitHub, that way your history will look like:

    Implement feature A
    Implement feature B

In either case, you end up with commits that have large diffs and touch many parts of the code base. Most features require multiple commits to implement. As far as I know, Github does not provide a facility to squash into multiple commits.

I don't find it as pretty as Phabricator's

"Merge branch 'dev-hello' into 'master'"

Phabricator makes it so that the squashed commit summary is the summary of the diff (merge request)

GitHub has a similar workflow - you can use "squash and rebase" as merge strategy, which adds a reference to the PR to the subject and combines the text of all commits into one.

But like the parent said, it's not nearly as fancy.

Of note is that in this workflow, the commit message is not subject to the same review process as the code and (hopefully) documentation etc, since it's in effect written by the user merging rather than the user committing.

Reply on news.ycombinator.com