15 ms·

GitHub merge queue is generally available

192 points by ingve 3y ago

zabil 3y ago
We've been using this for a few months to manage pull request merges for our mono repo. It's greatly improved the merge process. It makes trunk based releases faster and reliable. Kudos to the team for adding this feature.
- kami8845 3y ago
  Same here, the experience has been generally favorable.
- ploxiln 3y ago
  same ... it was pretty flaky early on, got stuck, double commits, not configurable merge-group size ... but it's pretty good now
- alwaysbeconsing 3y ago
  If you do squash merges, how does the queue handle the creation of the final commit message? We already have a problem with trash-filled message bodies with GitHub, and I don't want this to make it worse.
  - zabil 3y ago
    We turned on squash only merges and use the pull request description as the commit message. GitHub creates a temporary merge branch with the commit where you can run tests before the merge. So in the end it’s just one commit.
bob1029 3y ago
This is neat. I recall an old thread on HN where we were discussing different strategies for achieving this. That said, I can't imagine being in a position to need this. Right now we do 3-4 merges a day and it's really comfortable. If we got to 10 merges a day, I'd start asking why we are changing so much damn code in the same space/time. I know there are really good use cases for this tooling though.
- masklinn 3y ago
  One of the huge advantages of this sort of workflows is it avoid devs rebasing then pushing without having run the test suite on the rebase PR. It’s most important if the test suite is pretty slow though (e.g. minutes) as that makes it more likely you’ll get push races.
- crabbone 3y ago
  I worked in a place with 50-70 programmers, and we had couple dozens rebases during the day (I don't know why anyone would want to use merge). This was a project in its initial stage, so a lot of code needed to be written rather than revised, also, after some bad experience with trying to manage the project in multiple repositories, everything was brought under one roof. So, all teams were working with the same repository. In this situation, we usually had a significant chance of waiting for another commit to go through. We also had a system that's similar to what Github offers to manage queued rebases. This was amplified by even the sanity test being about 30 minutes long and the requirement that each commit be tested (so, if you try to rebase a branch with 10 commits, you'd have to wait 5 hours for it to go through). However, such cases would be very rare and anyone who needed to rebase such a branch would typically send an email asking for a particular day to get their changes in. To my memory, there were two instances of something like this happening. From what I could gather from the article and the comments, the system worked differently though. First of all, ours could try to rebase in parallel, so that if one rebase fails the test, another set of changes could be incorporated immediately. However, no attempt was made to see if the change set being submitted agrees with the changes in the pipeline. I think we might have tried that once, but later ruled this to be both confusing and in most cases catching very few issues anyways (it is in general rare that two developers work on the same exact files). The confusion part comes from detecting conflicts with the branch that doesn't get rebased due to the failed test, and then the developer who's notified about a conflict is left wondering about the real reason, because, usually, by the time they get to investigate it, the failed branch had been already changed by the branch owner. I also worked in larger companies, but usually they try to split the repository along administrative boundaries, and the number of people pushing to the same repository at the same time is not so big. They pay for it by having to invest a lot into release management, version synchronization across multiple teams, much more integration testing, worse understanding of the product by individual developers / teams, and, in general, lower quality of the product. But, off-the-shelf VCSs don't allow for sharing large repositories easily, and, of course, the problem this merge queue is trying to address would grow more severe with the size.
cprecioso 3y ago
I would love to use this at $daywork, but it has the unfortunate limitation that the merge group needs to pass the same checks as the branch itself, making it doubly expensive (esp. with something like Chromatic that is susceptible to flakiness and might need manual approval). I would love to be able to set different sets of checks that need to pass to add a PR to a merge group, and to the merge group itself to be merged, so we can better manage speed and cost.
- esprehn 3y ago
  Where do you see that limitation? The docs say there's a separate event for merge_group which I assume means you can configure different checks. https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue#triggering-merge-group-checks-with-github-actions https://docs.github.com/en/repositories/configuring-branches...
  - mfenniak 3y ago
    The branch protection rules that you apply are both used to determine if you can add a PR to the merge queue, and if the merged commit passes the merge queue checks and is OK. This isn't documented, but based upon experience using the beta.
    - masklinn 3y ago
      If the events triggering the jobs are different you can handle that there e.g. immediately succeed on a pr and actually validate on a queue or the reverse.
- mnahkies 3y ago
  Another option to workaround this could be to skip/noop checks based on the branch name prefix
- mfenniak 3y ago
  I was surprised by this weird limitation as well. However I found its easy to workaround -- I made my CI checks provide the skipped status when they run on the PR, and then provide the success/failure status when they run on the merge-queue branch. In a GitHub Action, this is was very easy: on: pull_request: merge_group: jobs: build: name: Whatever... if: github.event_name == 'merge_group' Then the task "Whatever" can be added as a required status check, and "skipped" is good enough to allow it to function on the PR side while it actually executes on the merge queue.
hesselink 3y ago
Does anyone else find this article unreadable? It sounds more like a marketing piece than an explanation of what merge queue is.
- jabradoodle 3y ago
  It's awful. I scrolled down to the how does it work section where the first sentence is: > Merge queue is designed for high-performance teams where multiple users regularly commit to a single branch Half of the how does it work section is buzzwordy fluff.
  - hashar 3y ago
    They don't need too since the link posted here is literally the press release announcement. For the inner details one should look at the documentation at https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue https://docs.github.com/en/repositories/configuring-branches... . It for example has a detailed example as how it handles a pull requests failing ahead in the queue https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue https://docs.github.com/en/repositories/configuring-branches...
- bezout 3y ago
  Yeah, the embedded video helps a bit.
- tottenhm 3y ago
  Yes. But look at the bottom. There's an image with the PR review screen. There's one change: * Normally, the big green button says "Merge pull request" * Now, the big green button says "Merge when ready" In a large project with lots of activity, a stampede of people pressing "Merge" at the same time will cause trouble. "Merge when ready" is supposed to solve this. It seems to mean: > "GH, please merge this, but take it slow. Re-run the tests a few extra times to be sure."
  - 3y ago
zeisss 3y ago
Seems to be only available to opublic repos or enterprise customers. At least I can't see the setting in my company's private repo
- michaelmior 3y ago
  > Pull request merge queues are available in any public repository owned by an organization, or in private repositories owned by organizations using GitHub Enterprise Cloud. Source: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue https://docs.github.com/en/repositories/configuring-branches...
ahmedfromtunis 3y ago
I hate the style of this post; too much fluff and so little information about the feature itself. Was this written by ChatGPT? Also, I don't think emojis belong in articles like this one. Maybe I'm getting old, but I don't like it.
- pachouli-please 3y ago
  > Was this written by ChatGPT Don't be ridiculous... Copilot did it.
John23832 3y ago
Squash and rebase. Linear commit histories.
- yohannparis 3y ago
  I don't understand how this is a relevant alternative? We are doing squash in our team, but merge queue seems to solve another problem. Could you explain, I'm really curious?
  - masklinn 3y ago
    It’s irrelevant, merge queues are orthogonal to the actual merge method.
- jakub_g 3y ago
  Not feasible if CI time > time diff between two merges (e.g. CI time is 15m but there's a PR merged every 5 min).
  - alkonaut 3y ago
    No problem unless it’s common for say 1 in 100 PRs to conflict at any point in their changes. If (say) one in 3 have conflicts, then it’s an obvious problem. So number of PRs alone shouldn’t be the limiting factor.
    - masklinn 3y ago
      Nah it's very much a problem then as well, because while not integrating a broken change is easy, fixing it once it's there can take a while as you try to disentangle what's what under pressure because at best other colleagues are hampered in their ability to work or worse use that as an opportunity to just merge their change in a hurry compounding the issue. If your integration branch is broken for half a day every week it gets old quick.
- paulddraper 3y ago
  Irrelevant. Regardless of the merge strategy (merge vs rebase), you will face the same problem with high-volume development relative to CI times. Merge vs rebase just affects how it appears in Git, not anything about breakage guarantees.
markmaglana 3y ago
This looks like the merge method used by Gerrit which I've missed. Good to know that it's now available on GH!
anacrolix 3y ago
I read the whole article and still have no idea how it works.
- viraptor 3y ago
  Merge: PR with tests passing on this branch gets merged. Merge when ready: PR with tests passing on a temporary branch (which includes all the PRs already queued up) gets merged when everything already queued up is merged. It prevents merging in a situation where branch A passes tests, branch B passes tests, but main+A+B would break.
smulc 3y ago
Note from https://github.com/orgs/community/discussions/46757 https://github.com/orgs/community/discussions/46757 that "@depdendabot merge command does not work" - we struggled with this for a while when testing a few months back before deciding to pause adopting this (merge queues are particularly useful for dependabot PRs where you likely have a stack of them that you want to approve and forget).
kubota 3y ago
What's the point if your pr is removed from the merge queue automatically when there are conflicts introduced? I thought that was the problem it was trying to solve.
- lordgilman 3y ago
  The problem it solves is that the vast number of PRs on a busy team don't conflict, both at the source level and the unit test/CI level, so you can increase the throughput of PRs by automating the merging process and merging multiple PRs at once.
- striking 3y ago
  It helps prevent incompatible PRs from shipping together. If two people merge incompatible changes at the same time (because both of them have a big green button), you might end up with a broken application. The way Merge Queue does its checks allows you to detect when these kinds of changes are being attempted and return one of the PRs to its author.
- masklinn 3y ago
  > I thought that was the problem it was trying to solve. Of course not since it’s not a problem it can solve. The problem it tries to solve is having to rebase / merge by hand, racing for CI, and the risk of going “fuck it” and merging a change with does not conflict but is semantically incompatible with a previous change. Most of the time your colleagues’ changes and yours don’t interfere, but on repos with lots of traffic losing the CI race and having to rebase, wait for CI again, rinse and repeat, gets old quick, when the test suite takes more than a few seconds.
pledess 3y ago
I'm surprised that a new merge tool in 2023 is still only about lexical code conflicts (such as competing line changes). I'd expect a tool for semantic code conflicts, e.g., developer A's PR extends the customer data structure with a new field (like upsellPotential) that customers shouldn't see, while developer B's PR adds the customer data structure to the JSON that's consumed by client-side JavaScript in the customer portal.
- striking 3y ago
  That's what your test suite is for.
reflexe 3y ago
It is only available for enterprise (which is unreasonably expensive: 21usd vs 4usd per month per seat). We asked our devops to develop something similar using our existing ci infra, took them a few days.
- plonk 3y ago
  What did they use? A GitHub Action that runs on PRs and creates other PRs with merged changes?
  - reflexe 3y ago
    I looked into that. Basically a GitHub action that goes over all of the prs that marked as "automerge" and updates them to master. It is not a perfect solution, but it works perfectly well for our monorepo.
MaxGabriel 3y ago
If anyone from GitHub is reading, any idea if the double commit bug the merge queue had has been fixed? https://github.com/orgs/community/discussions/36568 https://github.com/orgs/community/discussions/36568 (This was an issue for us during the beta)
- masklinn 3y ago
  There are comments upthread which mention hitting this issue and say that things got smoother and they’re happy now.
alkonaut 3y ago
Is this in/will this come to Azure DevOps any time soon? Any rumors?
- easton 3y ago
  Azure Repos feels like it's not getting a lot of updates anymore. They still only support ssh-rsa host keys for SSH Git, which seems like it would be something to fix after several years of OpenSSH having deprecated it. (But merge trains would really help too).
  - WorldMaker 3y ago
    I feel like the writing is on the wall that Azure Repos is supposed to finally get Dependabot, Security Token Scanning, and more security auditing tools 2-3 years after GitHub added all of those features and the brand name for that is "GitHub Advanced Security for Azure DevOps". That brand name says a lot (and not just because it is so long). I really wish Microsoft would just pull the trigger on Old Yeller at this point, it's almost worse watching it suffer so much.
barneygale 3y ago
Merge queues/merge trains solve a problem that only exists if you require all PRs/MRs to be based on the tip of the target branch. And there's little reason to do that unless your codebase is a total mess.
- muspimerol 3y ago
  I don't understand this, how could you be confident your changes won't break something if they are not based on the tip of a branch? What if other conflicting changes have been merged in the mean time?
  - barneygale 3y ago
    If conflicting changes have been merged in, GitLab/Hub will tell you that your branch has conflicts and prompt you to update/rebase on the target branch. That doesn't happen simply because your branch is out-of-date with the target.
    - muspimerol 3y ago
      There are two types of conflicts: literally changing the same lines of code (which you're talking about) and conflicts of business logic between features/modules (which I'm talking about). What if your PR depends on a database table that was dropped in the most recent commit? If your branch is based on an old commit, your tests might pass, because that table has not been deleted yet from your POV. But there will be a failure when you merge.
- aseipp 3y ago
  No, merge queue logic is still useful even if you use literal merges, or rebases. We used GitLab at my last job and had a "merge train" bot that would do more-or-less the exact same thing as GitHub does here, it would just literally use 'git merge' instead of 'git rebase'. No big difference in that regard. In any case, many teams and groups prefer reducing the number of merges to zero, if at all possible, and rebasing all final commits on top of trunk, to make the history shorter and more manageable. It isn't really that unusual at all these days. I've been working this way for years. But merge queues/merge trains are more a matter of team size/velocity/commit rate than it is anything to do with the merge algorithm, ultimately.
agumonkey 3y ago
This kind of synthetic branching seems to be useful in many places. I wonder who works on this.
foresterre 3y ago
> Any team that is part of a managed organization with public repositories and GitHub Enterprise Cloud users will be able to enable this feature on their respective repository and start streamlining their team’s pull requests immediately. I'm a bit sad that the merge queue is not available for personal accounts. I was hoping have it replace Bors, which has been deprecated since May 1st, 2023. https://bors.tech/newsletter/2023/05/01/tmib-76/ https://bors.tech/newsletter/2023/05/01/tmib-76/
- donatj 3y ago
  Yes. GitHub reserving features for organizations has kind of kludged up the whole service. Draft PRs for instance really should be available to everyone. I suspect they’re trying to do it as some sort of value add, but none of the features they are reserving are worth paying for on their own. It’s just an annoyance.
  - Nemo157 3y ago
    You don't need to pay to have an organization, I just created a personal organization to hold my non-experimental source repos.
  - aseipp 3y ago
    Draft PRs work on all repositories, even non-org ones, though? I used them like 2 hours ago. Or are there more features for Orgs? I do agree MQ being only for Orgs is really really annoying.
donatj 3y ago
> Any team that is part of a managed organization with public repositories and GitHub Enterprise Cloud users will be able to enable this feature on their respective repository and start streamlining their team’s pull requests immediately. If this describes you, then let the commit parties commence. That doesn’t sound very “Generally Available” to me, I really wish they’d stop this confusing feature differentiation. Just give everyone everything. Why can’t I use merge queue or my personal repos. It’d be very useful for merging a bunch of dependabot PRs.
- erikpukinskis 3y ago
  Because this is the kind of feature large orgs need which makes it a perfect upsell.
  - donatj 3y ago
    But no large org is using the free tier anyway?
    - plonk 3y ago
      Small-ish orgs with finite money can use the free tier if they don’t see a point.
- paulddraper 3y ago
  Fair question. Though FWIW, you have to have a fairly large scale for merge queues to be relevant in practice.
punnerud 3y ago
Drawback for SalesForce it’s that it use additional scratch orgs
elpakal 3y ago
How impactful is this if we don't require up-to-date on PR branches?

192 points by ingve 3y ago

We've been using this for a few months to manage pull request merges for our mono repo. It's greatly improved the merge process. It makes trunk based releases faster and reliable. Kudos to the team for adding this feature.

kami8845 3y ago
Same here, the experience has been generally favorable.
ploxiln 3y ago
same ... it was pretty flaky early on, got stuck, double commits, not configurable merge-group size ... but it's pretty good now
alwaysbeconsing 3y ago
If you do squash merges, how does the queue handle the creation of the final commit message? We already have a problem with trash-filled message bodies with GitHub, and I don't want this to make it worse.
- zabil 3y ago
  We turned on squash only merges and use the pull request description as the commit message. GitHub creates a temporary merge branch with the commit where you can run tests before the merge. So in the end it’s just one commit.

bob1029 3y ago

This is neat. I recall an old thread on HN where we were discussing different strategies for achieving this. That said, I can't imagine being in a position to need this. Right now we do 3-4 merges a day and it's really comfortable. If we got to 10 merges a day, I'd start asking why we are changing so much damn code in the same space/time. I know there are really good use cases for this tooling though.

masklinn 3y ago
One of the huge advantages of this sort of workflows is it avoid devs rebasing then pushing without having run the test suite on the rebase PR. It’s most important if the test suite is pretty slow though (e.g. minutes) as that makes it more likely you’ll get push races.
crabbone 3y ago
I worked in a place with 50-70 programmers, and we had couple dozens rebases during the day (I don't know why anyone would want to use merge). This was a project in its initial stage, so a lot of code needed to be written rather than revised, also, after some bad experience with trying to manage the project in multiple repositories, everything was brought under one roof. So, all teams were working with the same repository. In this situation, we usually had a significant chance of waiting for another commit to go through. We also had a system that's similar to what Github offers to manage queued rebases. This was amplified by even the sanity test being about 30 minutes long and the requirement that each commit be tested (so, if you try to rebase a branch with 10 commits, you'd have to wait 5 hours for it to go through). However, such cases would be very rare and anyone who needed to rebase such a branch would typically send an email asking for a particular day to get their changes in. To my memory, there were two instances of something like this happening. From what I could gather from the article and the comments, the system worked differently though. First of all, ours could try to rebase in parallel, so that if one rebase fails the test, another set of changes could be incorporated immediately. However, no attempt was made to see if the change set being submitted agrees with the changes in the pipeline. I think we might have tried that once, but later ruled this to be both confusing and in most cases catching very few issues anyways (it is in general rare that two developers work on the same exact files). The confusion part comes from detecting conflicts with the branch that doesn't get rebased due to the failed test, and then the developer who's notified about a conflict is left wondering about the real reason, because, usually, by the time they get to investigate it, the failed branch had been already changed by the branch owner. I also worked in larger companies, but usually they try to split the repository along administrative boundaries, and the number of people pushing to the same repository at the same time is not so big. They pay for it by having to invest a lot into release management, version synchronization across multiple teams, much more integration testing, worse understanding of the product by individual developers / teams, and, in general, lower quality of the product. But, off-the-shelf VCSs don't allow for sharing large repositories easily, and, of course, the problem this merge queue is trying to address would grow more severe with the size.

cprecioso 3y ago

I would love to use this at $daywork, but it has the unfortunate limitation that the merge group needs to pass the same checks as the branch itself, making it doubly expensive (esp. with something like Chromatic that is susceptible to flakiness and might need manual approval). I would love to be able to set different sets of checks that need to pass to add a PR to a merge group, and to the merge group itself to be merged, so we can better manage speed and cost.

esprehn 3y ago
Where do you see that limitation? The docs say there's a separate event for merge_group which I assume means you can configure different checks. https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue#triggering-merge-group-checks-with-github-actions https://docs.github.com/en/repositories/configuring-branches...
- mfenniak 3y ago
  The branch protection rules that you apply are both used to determine if you can add a PR to the merge queue, and if the merged commit passes the merge queue checks and is OK. This isn't documented, but based upon experience using the beta.
  - masklinn 3y ago
    If the events triggering the jobs are different you can handle that there e.g. immediately succeed on a pr and actually validate on a queue or the reverse.
mnahkies 3y ago
Another option to workaround this could be to skip/noop checks based on the branch name prefix
mfenniak 3y ago
I was surprised by this weird limitation as well. However I found its easy to workaround -- I made my CI checks provide the skipped status when they run on the PR, and then provide the success/failure status when they run on the merge-queue branch. In a GitHub Action, this is was very easy: on: pull_request: merge_group: jobs: build: name: Whatever... if: github.event_name == 'merge_group' Then the task "Whatever" can be added as a required status check, and "skipped" is good enough to allow it to function on the PR side while it actually executes on the merge queue.

hesselink 3y ago

Does anyone else find this article unreadable? It sounds more like a marketing piece than an explanation of what merge queue is.

jabradoodle 3y ago
It's awful. I scrolled down to the how does it work section where the first sentence is: > Merge queue is designed for high-performance teams where multiple users regularly commit to a single branch Half of the how does it work section is buzzwordy fluff.
- hashar 3y ago
  They don't need too since the link posted here is literally the press release announcement. For the inner details one should look at the documentation at https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue https://docs.github.com/en/repositories/configuring-branches... . It for example has a detailed example as how it handles a pull requests failing ahead in the queue https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue https://docs.github.com/en/repositories/configuring-branches...
bezout 3y ago
Yeah, the embedded video helps a bit.
tottenhm 3y ago
Yes. But look at the bottom. There's an image with the PR review screen. There's one change: * Normally, the big green button says "Merge pull request" * Now, the big green button says "Merge when ready" In a large project with lots of activity, a stampede of people pressing "Merge" at the same time will cause trouble. "Merge when ready" is supposed to solve this. It seems to mean: > "GH, please merge this, but take it slow. Re-run the tests a few extra times to be sure."
- 3y ago

zeisss 3y ago

Seems to be only available to opublic repos or enterprise customers. At least I can't see the setting in my company's private repo

michaelmior 3y ago
> Pull request merge queues are available in any public repository owned by an organization, or in private repositories owned by organizations using GitHub Enterprise Cloud. Source: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue https://docs.github.com/en/repositories/configuring-branches...

ahmedfromtunis 3y ago

I hate the style of this post; too much fluff and so little information about the feature itself. Was this written by ChatGPT? Also, I don't think emojis belong in articles like this one. Maybe I'm getting old, but I don't like it.

pachouli-please 3y ago
> Was this written by ChatGPT Don't be ridiculous... Copilot did it.

John23832 3y ago

Squash and rebase. Linear commit histories.

yohannparis 3y ago
I don't understand how this is a relevant alternative? We are doing squash in our team, but merge queue seems to solve another problem. Could you explain, I'm really curious?
- masklinn 3y ago
  It’s irrelevant, merge queues are orthogonal to the actual merge method.
jakub_g 3y ago
Not feasible if CI time > time diff between two merges (e.g. CI time is 15m but there's a PR merged every 5 min).
- alkonaut 3y ago
  No problem unless it’s common for say 1 in 100 PRs to conflict at any point in their changes. If (say) one in 3 have conflicts, then it’s an obvious problem. So number of PRs alone shouldn’t be the limiting factor.
  - masklinn 3y ago
    Nah it's very much a problem then as well, because while not integrating a broken change is easy, fixing it once it's there can take a while as you try to disentangle what's what under pressure because at best other colleagues are hampered in their ability to work or worse use that as an opportunity to just merge their change in a hurry compounding the issue. If your integration branch is broken for half a day every week it gets old quick.
paulddraper 3y ago
Irrelevant. Regardless of the merge strategy (merge vs rebase), you will face the same problem with high-volume development relative to CI times. Merge vs rebase just affects how it appears in Git, not anything about breakage guarantees.

markmaglana 3y ago

This looks like the merge method used by Gerrit which I've missed. Good to know that it's now available on GH!

anacrolix 3y ago

I read the whole article and still have no idea how it works.

viraptor 3y ago
Merge: PR with tests passing on this branch gets merged. Merge when ready: PR with tests passing on a temporary branch (which includes all the PRs already queued up) gets merged when everything already queued up is merged. It prevents merging in a situation where branch A passes tests, branch B passes tests, but main+A+B would break.

smulc 3y ago

Note from https://github.com/orgs/community/discussions/46757 https://github.com/orgs/community/discussions/46757 that "@depdendabot merge command does not work" - we struggled with this for a while when testing a few months back before deciding to pause adopting this (merge queues are particularly useful for dependabot PRs where you likely have a stack of them that you want to approve and forget).

kubota 3y ago

What's the point if your pr is removed from the merge queue automatically when there are conflicts introduced? I thought that was the problem it was trying to solve.

lordgilman 3y ago
The problem it solves is that the vast number of PRs on a busy team don't conflict, both at the source level and the unit test/CI level, so you can increase the throughput of PRs by automating the merging process and merging multiple PRs at once.
striking 3y ago
It helps prevent incompatible PRs from shipping together. If two people merge incompatible changes at the same time (because both of them have a big green button), you might end up with a broken application. The way Merge Queue does its checks allows you to detect when these kinds of changes are being attempted and return one of the PRs to its author.
masklinn 3y ago
> I thought that was the problem it was trying to solve. Of course not since it’s not a problem it can solve. The problem it tries to solve is having to rebase / merge by hand, racing for CI, and the risk of going “fuck it” and merging a change with does not conflict but is semantically incompatible with a previous change. Most of the time your colleagues’ changes and yours don’t interfere, but on repos with lots of traffic losing the CI race and having to rebase, wait for CI again, rinse and repeat, gets old quick, when the test suite takes more than a few seconds.

pledess 3y ago

I'm surprised that a new merge tool in 2023 is still only about lexical code conflicts (such as competing line changes). I'd expect a tool for semantic code conflicts, e.g., developer A's PR extends the customer data structure with a new field (like upsellPotential) that customers shouldn't see, while developer B's PR adds the customer data structure to the JSON that's consumed by client-side JavaScript in the customer portal.

striking 3y ago
That's what your test suite is for.

reflexe 3y ago

It is only available for enterprise (which is unreasonably expensive: 21usd vs 4usd per month per seat). We asked our devops to develop something similar using our existing ci infra, took them a few days.

plonk 3y ago
What did they use? A GitHub Action that runs on PRs and creates other PRs with merged changes?
- reflexe 3y ago
  I looked into that. Basically a GitHub action that goes over all of the prs that marked as "automerge" and updates them to master. It is not a perfect solution, but it works perfectly well for our monorepo.

MaxGabriel 3y ago

If anyone from GitHub is reading, any idea if the double commit bug the merge queue had has been fixed? https://github.com/orgs/community/discussions/36568 https://github.com/orgs/community/discussions/36568 (This was an issue for us during the beta)

masklinn 3y ago
There are comments upthread which mention hitting this issue and say that things got smoother and they’re happy now.

alkonaut 3y ago

Is this in/will this come to Azure DevOps any time soon? Any rumors?

easton 3y ago
Azure Repos feels like it's not getting a lot of updates anymore. They still only support ssh-rsa host keys for SSH Git, which seems like it would be something to fix after several years of OpenSSH having deprecated it. (But merge trains would really help too).
- WorldMaker 3y ago
  I feel like the writing is on the wall that Azure Repos is supposed to finally get Dependabot, Security Token Scanning, and more security auditing tools 2-3 years after GitHub added all of those features and the brand name for that is "GitHub Advanced Security for Azure DevOps". That brand name says a lot (and not just because it is so long). I really wish Microsoft would just pull the trigger on Old Yeller at this point, it's almost worse watching it suffer so much.

barneygale 3y ago

Merge queues/merge trains solve a problem that only exists if you require all PRs/MRs to be based on the tip of the target branch. And there's little reason to do that unless your codebase is a total mess.

muspimerol 3y ago
I don't understand this, how could you be confident your changes won't break something if they are not based on the tip of a branch? What if other conflicting changes have been merged in the mean time?
- barneygale 3y ago
  If conflicting changes have been merged in, GitLab/Hub will tell you that your branch has conflicts and prompt you to update/rebase on the target branch. That doesn't happen simply because your branch is out-of-date with the target.
  - muspimerol 3y ago
    There are two types of conflicts: literally changing the same lines of code (which you're talking about) and conflicts of business logic between features/modules (which I'm talking about). What if your PR depends on a database table that was dropped in the most recent commit? If your branch is based on an old commit, your tests might pass, because that table has not been deleted yet from your POV. But there will be a failure when you merge.
aseipp 3y ago
No, merge queue logic is still useful even if you use literal merges, or rebases. We used GitLab at my last job and had a "merge train" bot that would do more-or-less the exact same thing as GitHub does here, it would just literally use 'git merge' instead of 'git rebase'. No big difference in that regard. In any case, many teams and groups prefer reducing the number of merges to zero, if at all possible, and rebasing all final commits on top of trunk, to make the history shorter and more manageable. It isn't really that unusual at all these days. I've been working this way for years. But merge queues/merge trains are more a matter of team size/velocity/commit rate than it is anything to do with the merge algorithm, ultimately.

agumonkey 3y ago

This kind of synthetic branching seems to be useful in many places. I wonder who works on this.

foresterre 3y ago

> Any team that is part of a managed organization with public repositories and GitHub Enterprise Cloud users will be able to enable this feature on their respective repository and start streamlining their team’s pull requests immediately. I'm a bit sad that the merge queue is not available for personal accounts. I was hoping have it replace Bors, which has been deprecated since May 1st, 2023. https://bors.tech/newsletter/2023/05/01/tmib-76/ https://bors.tech/newsletter/2023/05/01/tmib-76/

donatj 3y ago
Yes. GitHub reserving features for organizations has kind of kludged up the whole service. Draft PRs for instance really should be available to everyone. I suspect they’re trying to do it as some sort of value add, but none of the features they are reserving are worth paying for on their own. It’s just an annoyance.
- Nemo157 3y ago
  You don't need to pay to have an organization, I just created a personal organization to hold my non-experimental source repos.
- aseipp 3y ago
  Draft PRs work on all repositories, even non-org ones, though? I used them like 2 hours ago. Or are there more features for Orgs? I do agree MQ being only for Orgs is really really annoying.

donatj 3y ago

> Any team that is part of a managed organization with public repositories and GitHub Enterprise Cloud users will be able to enable this feature on their respective repository and start streamlining their team’s pull requests immediately. If this describes you, then let the commit parties commence. That doesn’t sound very “Generally Available” to me, I really wish they’d stop this confusing feature differentiation. Just give everyone everything. Why can’t I use merge queue or my personal repos. It’d be very useful for merging a bunch of dependabot PRs.

erikpukinskis 3y ago
Because this is the kind of feature large orgs need which makes it a perfect upsell.
- donatj 3y ago
  But no large org is using the free tier anyway?
  - plonk 3y ago
    Small-ish orgs with finite money can use the free tier if they don’t see a point.
paulddraper 3y ago
Fair question. Though FWIW, you have to have a fairly large scale for merge queues to be relevant in practice.

punnerud 3y ago

Drawback for SalesForce it’s that it use additional scratch orgs

elpakal 3y ago

How impactful is this if we don't require up-to-date on PR branches?