31–40 of 71 posts
i would perform the tests before merging - rebase the pull request branch on top of master and run the tests, then merge using the --no-ff flag to ensure a merge commit is still entered
This is a real problem in my current place (huge monorepo, 100+ devs, 100+ merges per day). Like others said, "merge queue" is the solution. GitHub's one has been in beta for many months now. There are also dedicated companies doing this like https://mergify.com/ But there's several tricky aspects like "what if I want some commit to jump in front of queue?", compliance etc. Due to the multitude of requirements and of…
(disclaimer: I'm from the Mergify team )
Two things had to work or we would have lost all our sanity points (reference to Call of Chthulhu): automated checks of style, building, testing; and small PRs subscribing to the 'do one thing and do it well' approach.
As for the second, it's more doable than you might think - if you decomposed your work well. We decomposed our work at these levels on one project: product, demo capability, epic, task; the other project used feature, epic, task. Typically PRs were at the task level, though sometimes at PR level.
For us this had the added benefit that the developer velocity on these two projects exceeded the velocity of any of the other projects I've been on.
Some other tricks we used were to make sure we rebased our task branches from develop every morning (and if needed after lunch); each task branch had 1 person only working on it; where complexity warranted we created an Epic-### branch for that epic and treated it as a mini-develop for tasks on that epic.
Sounds like you want to implement something like merge trains?[0] [0]: https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-tr...
Another question I got on this. What do you do with merge conflicts between the branches? Do you then provide the system with patches for the merge conflicts somehow, so that it can resolve them as needed? E.g. when merging A, B and C. C might have no conflict with master or A but it has a conflict with B. Now for the queuing to work A -> B -> C it will have to know somehow how to patch C to fit on top of B. Maybe B…
Is it possible that the solution is to look at why there is such a high frequency of commits by different devs into the same main branch? Rather than look for a technical solution I would explore process and culture changes, such as having the various devs making all the different commits start pairing.
Our test suite takes about 30m to finish.
Is it possible that the solution is to look at why there is such a high frequency of commits by different devs into the same main branch? Rather than look for a technical solution I would explore process and culture changes, such as having the various devs making all the different commits start pairing.
i would perform the tests before merging - rebase the pull request branch on top of master and run the tests, then merge using the --no-ff flag to ensure a merge commit is still entered
With a sufficient number of merges, by the time your rebased branch's tests have finished running, your branch is no longer up to date with the main branch - so you get to rebase again, wait for tests again, etc.