I want to add a rule so the PR with open conversations can not be merged.
It occurs that I can find a typo in PR and add a comment and still approve the PR, so that an author has the opportunity to quickly correct this typo and merge the PR.
But I want it to be impossible to merge the PR until an author resolves the conversation.
Is it possible to do this?
It looks like they've added a branch rule option for this but it indicates that the functionality is still in Beta.
Simply go to Settings -> Branches and check the Require conversation resolution before merging field.
No, it's not possible to do that. Conversations and review comments aren't considered when performing merge checks.
If you want to prevent the PR from being merged, then you need to refrain from approving it or request changes if need be. The reason is that conversations can be resolved entirely by one party, so they aren't very effective at ensuring the user has done anything about them. The author could resolve it and merge without making any changes at all, and therefore it doesn't make sense to make this any sort of control.
Related
I am working on a repo where I am the owner and only author in it.
I want to have in my repo the same behavior as I would when working with a team that protects my branch from direct commits as they must go through a Pull Request. The reason for doing so is to protect from my own mistakes as I sometimes go back to main branch and accidentally push code to it. I want only code that passed through a Pull Request to be able to be merged to main branch.
In order to achieve such behavior I added the following rule to my main branch -
Which is almost what I need, expect that I am locked without the ability to approve my PR's as there is a message I get saying authors of the PR can't approve their PR's - a logical error nonetheless, but if I am working alone in the repo this is not what I am looking for.
How can I achieve what I am looking for?
Simply disable "Require approvals" (the second checkbox in your screenshot), you will still be required to create a PR.
You can merge your own PRs, the only thing you cannot do is to approve your own work (after all: why would you? Hopefully you deem your own changes good!)
Using Github to manage a repo, by default, the pull request title is used as the merge commit message.
I would like to use the pull request body as the default merge commit message. Yes, I could copy-paste this into the editor whenever merging a PR, but I'd rather automate this part of the process and not rely on the PR author to remember to copy-paste.
Is there a configuration option to do this somewhere that I'm missing, or a plugin or automated tool that does something like this? Thanks!
A screenshot of creating a Github PR to make it clear:
(Note that I'm not looking for evangelism about what PRs or commit messages should look like, just technical advice on how to achieve a specific goal.)
Per this documentation, the default generated commit message depends on the number of commits in the PR - if it's one, that commit message is used. If it's more, the summary will be the PR title, and the description will be a list of the commits in the PR.
The only configuration option I find in the docs relating to this is here, which allows you to default to using the PR title for all squash merges. Currently I don't believe there is a way to accomplish what you want without just copy-pasting it yourself.
tl;dr I created a PR in someone's stead. Now I can't submit a review. Is there a way around?
The other developer messed up and merged a feature to the target branch, so I reverted their changes, fixed the issues, squashed and rebased their work while still keeping their authorship on the commit and I created a new pull request. Now, when I want to submit a review, it prevents me to Request changes, because now I am the author of the PR. How can I change it so that the other developer is responsible and receives the review?
You cannot change the author of a pull request or create one in somebody else's name. GitHub doesn't allow this because it would permit people to forge pull requests and let another person receive negative feedback. For example, if I opened a PR in your name containing something wildly inappropriate (say, a racist slur), you'd be blamed for it unfairly. Moreover, in some regulated environments, keeping an accurate record of who contributed code is very important for legal reasons, which is another reason why this isn't permitted.
In most cases, if a commit gets reverted, then just have the original author open a new PR. Clearly they'd wanted to submit the code in the first place. You can even create the branch for them with their commit squashed and prepared, as long as they open the PR. This is a case where a helpful conversation with another contributor goes a long way, and presumably you'd want to let them know in a kind way that they made a mistake and that you reverted it anyway. Since there's no way to create a repository on behalf of another user, you should close your PR and ask them original submitter to open it instead.
I think it's obvious why you can't approve your own PRs. I can see that this is a situation where requesting changes might be useful, but I suppose the rationale is that you wouldn't have opened the PR if you thought it needed improvements, and if you later learned that, you certainly would revise it instead of merging it.
Although bk2204's answer is correct and explains why there isn't a one-button solution, it doesn't address the actual question of:
How can I change it so that the other developer is responsible and receives the review?
The only way to that is to close out the PR you opened and have them open it instead.
As repo reviewer you’ll get PR, review the code (semantics) and Github will simply check about merge ability of the changes.
If a (remote) collaborator works on a outdated master branch will potentially have positive feedback from tests. But might have hidden semantics issues or might break tests when merged on the latest master commit (hopefully at CD's pipeline test phase and before going to prod).
Said so, I agree that it’s always up to the reviewers to ensure that the PR should not break.
But I’m also thinking, why not helping the reviewer by warning that you are currently merging changes starting from a branch that is behind X commits from master?
Does it make sense? Or maybe there’s already something (invisible to me) that might alert us inside a PR UI about it?
P.S. I understand that.... if the above is confirmed this is not going to be a real question but a feature request to Github... but I think it's worth questioning about this.
You can make the master branch protected and require that the branch in the PR be up to date before allowing a merge. The GitHub documentation describes how to do this.
On a Github project, I see a guy made a pull request in Pull Requests section, but I find he made many mistakes so his code need to be corrected. Instead of asking him to change his code, is it possible to do it by myself (that is, I want to correct his code by myself)? and how?
I'm also a member of that project, and I'm new :)
Enabling repository maintainer permissions on existing pull requests
Pull request creators can give these permissions on each of their pull requests when they initially create a pull request from a fork or after they have created the pull request.
On GitHub, navigate to the main page of the upstream repository of your pull request.
In the list of pull requests, navigate to the pull request that you'd like to allow commits on.
In the right sidebar of your pull request, select Allow edits from maintainers. You can change these permissions at any time by unselecting this option.
More details on github help page: Allowing changes to a pull request branch created from a fork
TL;DR
Author of PR can modify an existing pull request to let repository maintainers make commits to your branch.
In order to allow you to make commits to others PR - the author has to set checkbox from the left:
Assuming the original author is responsive enough, it’s always better to ask them to fix it (unless the change is an obvious typo fix, maybe). They might have a reason for writing it the way they did.
If the author isn’t responsive and you’re deciding whether to fix it in place or with a new commit, ask yourself which way the history reads more clearly. If the commit would introduce a regression, you should probably fix it in place (to avoid breaking bisectability). If it handles some cases and you just want to add more cases without significantly changing the existing code, it might be better to add a new commit.
If you do amend the existing commit in any way, make sure to leave a note in the commit message explaining what you changed. One typical style is to leave a note in square brackets, grouped with any Signed-off-by: lines (if applicable):
[your.email#example.com: Refactor new cases into a function for clarity]
For example: linux.git commit b44129b3.
via https://www.quora.com/GitHub-Is-it-bad-etiquette-to-change-someones-pull-request-before-committing