8 ms·
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
by brodney 12y ago
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?
- hk__2 12y agoA common practice is for pull requesters to rebase their branch on the upstream branch to avoid these conflicts.
- maaaats 12y agoBut if the master/upstream is changed, the feature branch must be updated again (manually).
- taeric 12y agoThere 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.