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.
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.
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.
6 comments
[ 858 ms ] story [ 1061 ms ] threadhttps://github.com/jeresig/pulley/blob/master/pulley.js
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.
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.