On Coursera course Version Control with Git, I encountered a problem below:
Which one of these statements is true?
A pull request must be made from a forked repository.
A pull request can be made only when a branch is being merged.
A pull request can act as a form of review and approval.
From my perspective, both 1 and 3 are correct.
Can someone point out which choice is correct, which are incorrect, and provide reasons?
A pull request can also be made on your own repository by members of that project, so the first choice is not correct.
A pull request can also be made between commits, tags, and earlier points in time, so the second choice is not correct.
The third point is true. So that's the answer.
Your question is technically about Github, not Git. Git doesn't have pull requests.
Third one statement is true. because we can create pull request without being merged and can be created without fork a repository. And we create a pull request for review the changes first then we're going to merge them into repository for which we created pull request.
Related
I am trying determine the merge method applied to a GitHub pull request.
There is a merge_method attribute on the API for merging a PR.
https://docs.github.com/en/rest/reference/pulls#merge-a-pull-request
But I do not see this available on the response for the GET
https://docs.github.com/en/rest/reference/pulls#get-a-pull-request
I'm not finding much about this anywhere, has anyone come up with a clever solution to compute this value? Or will it be added the API in the near future?
GitHub doesn't store this information because the pull request can have been merged by means other than the merge button on a pull request.
For example, if I perform a manual merge of a PR and the main branch myself and then push the result to the main branch, that will close the pull request as merged, since the main branch now includes the head of the pull request. This is also true if I do a fast forward merge, which might be the behavior done by a rebase through the web interface.
You can even close a pull request for branch A by merging it into branch B and then merging branch B into the main branch, using the web interface, the API, or otherwise. GitHub uses this technique for its deployment trains, where B is a train and A is a normal feature branch.
Essentially, any time the main branch is updated to include the head of the feature branch in a pull request, that pull request is considered merged. The exception is squash merges, where this doesn't happen, which are treated specially. So there's no guaranteed way to find out this information.
Seems like you can get it like this from their GraphQL API:
{
repository(owner: "TeamCodeStream", name: "codestream") {
viewerDefaultMergeMethod
}
}
Method reposted from this SO answer: https://stackoverflow.com/a/64146400/12206312
We currently have a GitHub repository where our master branch is protected for everyone except admins, who are able to commit and push directly to the branch without first opening a pull request. We're looking to find a way to send a Slack notification anytime an admin commits directly to master in order to call attention to the fact that there was an override of the branch protections. This may happen intentionally due to extreme circumstances or, worst case, by mistake (which will need to be addressed).
This seems like it'd be possible with a combination of the GitHub Slack action, the if key on the job/step definition, and ideally some piece of information from the push event JSON.
The last part is where I'm stuck: I don't see an obvious way to use the data contained in the push event to differentiate between one-off commits that would violate our branch protection policy and a normal/compliant pull request.
Does anyone have any ideas as to whether or not this is possible? Perhaps there's another event that I should be attaching this workflow to that would give me the information I'd need to tell the difference and launch the Slack notification?
In general, using GitHub Actions to do this kind of notification is problematic because the user can simply remove or neutralize the code that reports this and then push to the main branch. The Actions workflow that's used will be the one pushed into the repo as part of that commit, so this won't be an effective control.
You'd want to probably instead use a webhook to notify a service of this fact and then look at the HEAD commit, parse the commit message to extract the PR number, and verify that the second parent of the commit is the same as the head of the PR. Note that this won't work if you're using squash merges, because there's no easy way to verify that the commit created by a squash merge is the same as the one created by the branch from which it was created.
I'm a bit surprised to learn that Github doesn't seem to allow the creation of a pull request between two identical branches. Is there a rationale to this? We have been building a workflow using WIP Pull Requests, and not being allowed to do this is annoying. We want to create the pull request at the beginning, in anticipation of future work to merge.
Is there a way to do it that I'm not seeing?
I'm quite new to GitHub and I'm not sure how I should behave about the number of pull requests I send to a certain project.
Is there such a thing as too many or too frequent pull requests?
Are there general guidelines to follow?
The naming convention for a pull request is your own to make.
The idea is to make a small coherent change that can easily be merged back and tested.
By "coherent", I mean "which introduces only one change or new feature".
It is best to isolate that change in its own branch, that you will push to your fork, and from which you open a new PR: see "couple of tips for PR".
You usually should have one pull request per issue. You should also squash your pull requests to a single commit. Your commit message should be very specific.
Suppose I have a following situation. Long ago I published some useful code on Github and a lot of people forked it since then. Now I find some really serious error (like a buffer overrun) in my code and fix it and I realize that all forks should better have that fix, otherwise Bad Things™ might happen.
How do I notify owners of all forks that there's this critical change they'd better pull?
An upstream repo doesn't really know about its downstream repo (see "Definition of “downstream” and “upstream”").
And you cannot make a pull request to a fork (that wouldn't scale well anyway).
So the easiest was is to count on the other developers to update their local clone with your latest changes, which will include your latest fixes.
You can update your README.md for all to see, but you cannot really "broadcast" to all the forks (not to mention all the direct clones you have no knowledge about).
Anyway, if they want to contribute back, you will reject any pull request which isn't fast-forward.
That means they will have to rebase their work on top of the latest from "upstream" (your repo), before pushing to their fork and making said pull request.