3 ms·

Ok this is nice. Of course, if you're just rebasing before reviewing and merging the PR into master it makes this pointless. Odd that they never mention this i

Ok this is nice. Of course, if you're just rebasing before reviewing and merging the PR into master it makes this pointless. Odd that they never mention this in the post, I was under the assumption that rebasing before creating the PR is standard practice, at least that's how we do it at work and on all the projects I've contributed to. EDIT: I've never used bitbucket, so maybe this is just a github community thing with the rebasing?

firethief 12y ago
That's a good (and standard) practice that solves the problem if your project never has more than one PR open at a time.
Nemo157 12y ago
For smaller projects that's fine, but if you have a lot of outstanding pull requests under discussion that's a lot of continual rebasing as they each get merged. (What if the two fee fixes in the article were done at the same time and reviewed by different project maintainers?)
- jfaucett 12y ago
  That sounds really unorganized to me at least, I mean the linux kernel is large and there's only one guy at the end of the day merging all that stuff. I would think that in larger projects a better practice would be a distributed hierarchy of merges until a PR finally got submitted to master, not a massive blob of just send everything to master as a PR and let various maintainers merge whatever at will.