Ask HN: How are pull requests integrated in a repo with high commit frequency?
11–20 of 71 posts
Re: Ask HN: How are pull requests integrated in a repo with high commit frequency?
#12Re: Ask HN: How are pull requests integrated in a repo with high commit frequency?
#13Earlier quoted context omitted.
Last time I checked they don't exist in GitHub, but it seems like a really good way to counteract this problem.
Almost there: https://github.blog/changelog/2021-10-27-pull-request-merge-...
Re: Ask HN: How are pull requests integrated in a repo with high commit frequency?
#14Re: Ask HN: How are pull requests integrated in a repo with high commit frequency?
#15We run the acceptance tests for all PRs and also the main branch after each change. So a given PR needs to be 'green', and if we merge the PR then we run the tests on the integration branch too. If the integration branchs gets broken somehow, then all merges stop -- we don't merge any further PRs into a 'broken' branch.
We have tried the option of always rebasing PRs on the most recent integration branch and re-running the tests, but that results in exponential number of builds.
Of course you need a meaningful build farm -- we have around 1000 CPU cores for ~30 developers that are fully utilised during work hours.
Re: Ask HN: How are pull requests integrated in a repo with high commit frequency?
#16Re: Ask HN: How are pull requests integrated in a repo with high commit frequency?
#17Check out something like Bors, which implements a paradigm that fixes this class of issue: https://github.com/bors-ng/bors-ng (Homepage: https://bors.tech/ )
Even if you don't have a supper high commit frequency it is still nice to enable certain rebase/stacked PR workflows. Which can remove a lot of friction even for teams which "just" have idk. 6 PRs merged per day (but other PRs which are based on top of this PRs in review and progress maybe stacked multiple layers deep).
Re: Ask HN: How are pull requests integrated in a repo with high commit frequency?
#18Sounds like you want to implement something like merge trains?[0] [0]: https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-tr...
This is a great solution and while I was at Google I noticed several high commit frequency teams using this strategy. Of course Google had built a bunch of custom tooling and infrastructure around it, so I can’t vouch for how easy it would be to integrate into a different company’s dev workflow, but if there are enough developers to make it worthwhile, then tasking a few developers with setting this up should be a us…