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?
Related
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.
Research I've done before raising this question:
[github] single user pr - no relevant results
[github] single user pull request - no relevant results
[github] approve own pull request
github protected branch require pull request (Unanswered)
A potentially relevant question, but around a multiple user environment, so there were workarounds. I don't have a workaround.
'[github] approve own pr` - no relevant results.
Quite a few Google searches
So my problem is simple: I have a personal GitHub repository that I am using to manage my website code. I would like to prevent accidental check-ins to the master branch because I do not want the CI/CD pipeline that I'm building to trigger unless a feature is complete; I'm planning to use issue-linked feature branches to handle updates.
My problem is that I cannot seem to set this up without having someone else to approve the pull requests, which I don't have. So the question is: How, other than creating a secondary git account to handle PR's, can I protect a branch to prevent accidental check-ins from happening, without having someone else on my team to approve those pull requests?
I know that I can do this in Azure Repositories, however, I quite like the GitHub environment so I'd rather do this in GitHub.
I managed to work around this. At the time I made this request, I didn't have automated tests set up (Something I believe all projects should have for completeness). When I set up validation requirements to merge into Master, I could not directly check-in to Master because those checks had not been run.
I could still approve the PR myself, so that was allowable, however, I also had to ensure that all pipeline checks had completed before that PR could complete.
It's not a complete answer because if you are not running a CI/CD pipeline with test running you will not be able to take advantage - but it's easy enough to set something dummy up that will always pass to enable this solution. Until GitHub.com provides a self-approval allowance, it seems to be the best answer.
I'm always happy to hear alternatives though!
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.
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.