4 ms·

I'd be interested to know how this scales on a larger team. Looking at the number of open PRs on some of our repos, I would guess doing this in a larger organiz

• breatheoften 10y ago
  I think it would scale pretty far based on my experience with the process on our team. I'd see more blockers to scaling team size coming more from other factors rather than the merge strategy -- things like the quality of tests and probability of problematic merge conflicts -- which I think would depend ultimately more on the code organization/team-member communication than the merge strategy. I think Facebook uses a souped up version of this strategy (based on how I interpret their presentation on it anyway). It seems like the engineer ships off a commit, and then it goes into a review branch where it gets automatically rebased against master continuously while waiting for review. When it passes review it goes onto master as the newest commit -- if a conflict happens before the review completes or during the final rebase then the engineer is notified to resolve the conflict and push again -- I think review needs to happen again in this case -- but it makes sense to do so as the first review was done without awareness of the change that caused the conflict ... I'm sure I don't describe their actual process accurately but I think it something along these lines ...