Hacker News Reader

I really like the idea of merge conflicts being resolved in the open in a pull request, instead of the pull requester working in seclusion. For those of us with projects on GitHub, is there any way to replicate this behavior there?

View on HN

A common practice is for pull requesters to rebase their branch on the upstream branch to avoid these conflicts.

But if the master/upstream is changed, the feature branch must be updated again (manually).

There is no magic to avoid this problem. If you are trying to get changes into a repository that is constantly changing with no good isolation of concerns, then expect pain.

Otherwise, merges really are better from most perspectives. I can trust people doing pull requests to have tested their code. Looking at the log, I can get an idea of whether or not their code was tested with someone elses. Something I can not do with a pure "rebase and push" mentality.

Reply on news.ycombinator.com