Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge strategies #17

Open
AlexAxthelm opened this issue Feb 1, 2024 · 4 comments
Open

Merge strategies #17

AlexAxthelm opened this issue Feb 1, 2024 · 4 comments
Assignees
Labels

Comments

@AlexAxthelm
Copy link

Some of our repos have we don't have consistent merge strategies on our repos, and I don't know if that's important or not

Also consider the merge queue, which is in place on some repos (and I don't really understand how it works or why it's important)

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github

cc @cjyetman

@cjyetman
Copy link
Collaborator

cjyetman commented Feb 1, 2024

The repos I maintain only allow "squash and merge", which I have a very strong preference for.

I think two of the repos I maintain have merge queue enabled. It was mostly an experiment once it became available. I'm not totally convinced with it. I like that when I/we are doing rapid development that we don't have to "update branch" on every open PR as we're merging things, but it also introduces some weirdness, like occasional delays in the PRs merging and occasional odd behavior with Actions running in the queue. Honestly, I'm tempted to turn it off in those repos.

@jdhoffa
Copy link
Collaborator

jdhoffa commented Feb 2, 2024

Yeah, my repos are all also set to "squash and merge" by default (and other options removed). Would be happy to align on this (but also happy for this to be maintainer-managed if people have strong preferences).

I tend to prefer not using the "merge queue" for the most part. The "update branch" thing is a bit annoying, but I don't think it's the worst thing in the world to have a bit of friction when we are rapid-fire merging PRs (this is usually when bugs are introduced anyway...)

Also not sure it matters, but "merge queue" cannot be used in conjunction with "wait for successful deployment". I don't know what the latter does/ how useful it is, but just judging by the name it sounds maybe interesting for ensuring e.g. that pkgdown sites build before a PR can merge, which I see potential value in:

Screenshot 2024-02-02 at 07 18 55

@AlexAxthelm
Copy link
Author

worst thing in the world to have a bit of friction when we are rapid-fire merging PRs

Isn't the merge queu designed for exactly that situation? (many PRs to busy branches)

@jdhoffa
Copy link
Collaborator

jdhoffa commented Feb 2, 2024

What I meant is adding friction that requires someone to manually inspect things. Merge-queue automates pulling and merging of branches (rather than manually updating them when they fall out of sync). I fear things may get missed if we implement this

Although also, hopefully, now that we have maintainers the "rapid fire merging of PRs to main" may be a bit less frequent? Maybe not

@jdhoffa jdhoffa self-assigned this Feb 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants