Hacker News Reader

Comment by mkesper | Hacker News Reader

You'd want to use a repo that only allows fast-forward and rebase everything that would be a merge. We use Gerrit for that.

View on HN

Yup, that's what I'm arguing in favour of. I systematically disable merge commits on every repo I manage.

I suspect that if merge-commits hadnt been the default on github since forever, it wouldnt have so many proponents.

> I systematically disable merge commits on every repo I manage.

Do you have buy in from other team members for this?

Also what do you do if master needs to be merged back into develop? Do you really rebase develop and make everyone fiddle with all their feature branches?

There is no develop, master is continuously deployed. Users can create feature branches and PR them but there is just no merge commit, they are pulled in fast-forward. In projects where I need stable releases, I create stable/1.2.x type branches off of master at a point in time. I cherry-pick commits onto it after the first release if there are subsequent ones.

You can see this in action here:

https://github.com/dj-stripe/dj-stripe/commits/master

https://github.com/dj-stripe/dj-stripe/commits/stable/1.2

Though fast forward merge commits (where the referenced tree is the same as referenced by the second parent) can be useful because they provide a way for you to group related commits for a feature together (git log merge_commit^..merge_commit^2). There are features that require more than a single commit to implement.

Reply on news.ycombinator.com