GitHub Merge Button - What Were they Thinking?

That button is a convenience for the "Hey I fixed a typo in your README"-type changes. Of course for a major feature addition you'll still want to do it the old way, which is obviously still possible.

They were probably thinking "Let's make our product more convenient and easier to use."

I used this button 3 times today and am happier for it.

I made these same complaints in their blog post comments when it came out. They made it harder to test code without first publishing it (i.e. welcome to CVS) and in the trivial cases where someone submits a spelling fix to your docs and you're sure it won't break anything, it now introduces two commits to do that, the second (the one showing at the top) providing potentially much less information.

I think it's good that they're making things easier, but fork queue (which seems mostly abandoned these days) seemed to solve these problems better. Understanding of course that none of cherry-picking, forced recursive merging or fast-forward merges is always right for everyone.

It thoroughly depends on the use case. If someone's submitting a documentation change, I have no problem at all merging in with the merge button. It's perfect.

I think the button should be used sparingly, but I'm extremely happy that it's there.

Small changes to a non-crucial project shouldn't be that big of a deal. Bigger projects typically have a more proper master/develop branch structure, and that unstable branch is there for a reason.

Also, GitHub is often used privately by trusted teams, so merging a repo from a colleague or coworker without testing first could be proper in many situations.

Checkout pulley

https://github.com/jeresig/pulley/blob/master/pulley.js