7 ms·

Sounds like you want to implement something like merge trains?[0] [0]: https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-trains/ https://about.gitlab.c

by Revell 4y ago

Sounds like you want to implement something like merge trains?[0] [0]: https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-trains/ https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-tr...

carlmr 4y ago
Last time I checked they don't exist in GitHub, but it seems like a really good way to counteract this problem.
- tdumitrescu 4y ago
  Almost there: https://github.blog/changelog/2021-10-27-pull-request-merge-queue-limited-beta/ https://github.blog/changelog/2021-10-27-pull-request-merge-...
  - jeremy_k 4y ago
    To note, we signed up for the beta and got accepted in last week. Haven't turned it on yet though.
- deleted 4y ago
  [deleted]
chrisshroba 4y ago
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 useful allocation of engineer time.
- heavenlyblue 4y ago
  GitLab has this feature.
  - geraldcombs 4y ago
    Not for fast forward merges.
vasco 4y ago
Merge trains are the way. They do optimistic testing of the prior branches in the queue so the happy path goes fast.
carlmr 4y ago
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 breaks if it is not working after merged into A, and then the queue becomes A -> C -> B (modified), now B probably needs a patch to merge cleanly on C?
- Communitivity 4y ago
  The developer whose task branch had merge conflicts was responsible for resolving the merge conflicts, and doing sidebars as needed where a discussion of the approach was warranted. They would resolve those conflicts in their branch before the PR was submitted. If the conflicts happened between submission and approval then the conflicts would still be resolved on the task branch before merge.
  - carlmr 4y ago
    >The developer whose task branch had merge conflicts was responsible for resolving the merge conflicts But that's exactly my point. The first PR to merge cleanly will determine whether the next PR causes a merge conflict or not. At the time of merging, none of these PRs had a merge conflict. We often have 10 conflicts between PR admission and approval.
    - avisser 4y ago
      > We often have 10 conflicts between PR admission and approval. I don't think a devops solution can remove those conflicts. At least not all of them. If you have devs in the same hot-spots of the code, you're going to get conflicts. Maybe refactoring can address some of this core issue.
    - deckard1 4y ago
      The key is to reduce the number of developers touching a specific section of code, and line up all tickets and hand them over to a single developer (or two). And yeah, management won't do it. Fred Brooks wrote an entire book about this in 1975 that no one reads today and everyone would certainly ignore if they did read it. Because it tells you the unvarnished truth about the nature of communication and information flow within an organization. Such is the state of things in our industry. Sweet little lies.

by Revell 4y ago

carlmr 4y ago

Last time I checked they don't exist in GitHub, but it seems like a really good way to counteract this problem.

tdumitrescu 4y ago
Almost there: https://github.blog/changelog/2021-10-27-pull-request-merge-queue-limited-beta/ https://github.blog/changelog/2021-10-27-pull-request-merge-...
- jeremy_k 4y ago
  To note, we signed up for the beta and got accepted in last week. Haven't turned it on yet though.
deleted 4y ago
[deleted]

chrisshroba 4y ago

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 useful allocation of engineer time.

heavenlyblue 4y ago
GitLab has this feature.
- geraldcombs 4y ago
  Not for fast forward merges.

vasco 4y ago

Merge trains are the way. They do optimistic testing of the prior branches in the queue so the happy path goes fast.

carlmr 4y ago

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 breaks if it is not working after merged into A, and then the queue becomes A -> C -> B (modified), now B probably needs a patch to merge cleanly on C?

Communitivity 4y ago
The developer whose task branch had merge conflicts was responsible for resolving the merge conflicts, and doing sidebars as needed where a discussion of the approach was warranted. They would resolve those conflicts in their branch before the PR was submitted. If the conflicts happened between submission and approval then the conflicts would still be resolved on the task branch before merge.
- carlmr 4y ago
  >The developer whose task branch had merge conflicts was responsible for resolving the merge conflicts But that's exactly my point. The first PR to merge cleanly will determine whether the next PR causes a merge conflict or not. At the time of merging, none of these PRs had a merge conflict. We often have 10 conflicts between PR admission and approval.
  - avisser 4y ago
    > We often have 10 conflicts between PR admission and approval. I don't think a devops solution can remove those conflicts. At least not all of them. If you have devs in the same hot-spots of the code, you're going to get conflicts. Maybe refactoring can address some of this core issue.
  - deckard1 4y ago
    The key is to reduce the number of developers touching a specific section of code, and line up all tickets and hand them over to a single developer (or two). And yeah, management won't do it. Fred Brooks wrote an entire book about this in 1975 that no one reads today and everyone would certainly ignore if they did read it. Because it tells you the unvarnished truth about the nature of communication and information flow within an organization. Such is the state of things in our industry. Sweet little lies.