I recently merged a branch into master and want to delete it now that I'm done with it. But github tells me that I can't delete it because some open pull request depends on it. How do I find out which pull requests depend on this branch?
To find the open pull requests which depend on a particular branch called foo (i.e. pull requests for merging other branches into branch foo), use the following Filter query in the Pull requests tab:
is:pr base:foo is:open
This will identify the Pull Requests preventing the deletion of branch foo
I found that one of my open pull requests was trying to merge into the branch I was trying to delete, instead of merging into master as it was supposed to. Fixing this allowed me to delete my branch.
I could not find a way to easily view all the open pull requests involving any given branch, so I had to go through my open PRs one by one.
Related
I'm defining branch protection rules on GitHub, and I would like to know if is there any way to define a Pull Request flow like: qa --> main.
I know it's possible to require pull request before merging (on Require a pull request before merging flag under Branches > Branch protection rule), but I didn't find any option for defining this flow.
There's no way on GitHub to force a source branch to be fixed to a certain value, but you can solve this problem with a required CI check that fails if the PR to main has the wrong source branch. That's the usual way that people handle this sort of issue.
New to GitHub, I have created a remote PRIVATE repository called X, and have a collaborator -person Y. Currently, person Y can simply accept the invitation to be a collaborator, and without forking the repo, simply make an edit, commit changes, and it appears on the master branch. This is obviously undesirable and it seems nonsensical that this is even allowed by default.
I would like person Y (collaborator) to:
-have to fork the repository and work only on the forked repo
-have to make changes ONLY via a pull request
-have to have a pull request, accepted/approved by me, before it is committed to master.
I looked through some answers, and tried:
-going to settings
-going to branches (on the left)
-changing access rights
I noticed however, that it required an upgrade.
I am certain I have heard/read that GitHub allowed full features for up to three collaborators.
Other similar questions on SO, have 0 answers.
I have also seen this option in settings:
"When merging pull requests, you can allow any combination of merge commits, squashing, or rebasing. At least one option must be enabled. If you have linear history requirement enabled on any protected branch, you must enable squashing or rebasing."
Allow merge commits
Add all commits from the head branch to the base branch with a merge commit.
It isn't clear to me what the above is referring to. If I checked that, would it stop all commits from collaborator's from being directly pushed to the master branch without authorisation?
Update:
I noticed some answers that suggested this (protecting a branch) cannot be done, but it is good practice to simply AGREE to always create a pull request. I require a pull request to be mandatory - if it is not enforced, an accidental push to master could obviously occur.
The question then is, what are workarounds for this (without having to pay).
Forking? How do you 'grant' access to another user to a PRIVATE repository. I could only see the option to share access by inviting as a collaborator.
There is this option which says: Default branch
The default branch is considered the “base” branch in your repository, against which all pull requests and code commits are automatically made, unless you specify a different branch.
In the above case, how would I go about creating a copy of the master branch, as it were, for collaborator's to work off of, so that the actual master branch is 'protected'?
The only other option I can think of is to create three levels.
One: Me: Project (with Master branch protected because I only grant access to -me 2)
Two. Me 2: I am granted collaborator access and I fork the project. (call it something else)
Three. I then grant collaborator access (if this is allowed) to the forked project, to someone else. This way, the collaborator can make changes to the forked project in Part 2, but not the original master project in Part 1.
Again, this all seems terribly long winded and unnecessary when all that is needed is for the master branch to be protected, only allowing pushes to master via pull requests which need to be authorised.
Any other options? Any advice or suggestions would be appreciated.
How do I go about making my pull requests have only the changes made on the new branch? Every time I push a branch it has all the changes from the previous branches included in the pull request also.
My manager is really big on making sure we do small PRs and have only the new changes on each one for easy review, but I'm at a complete loss as to how to do this. This is my first dev job and up until now I unfortunately haven't been able to do group work so managing PRs that might be a while before they are merged in is totally new to me.
So far I've only found how to cherry pick commits, is this the only way?
If I understand you right, you have a main branch (master?) that contains the latest version of your software and you have one or more other branches that contain modifications. You do some more modifications in that other branch and if you create a pull request it will contain all other changes.
The most simple solution I can think of is to use dedicated branches for all changes. Before starting to work, create a new branch from the main branch with the ticket ID, work description or whatever you use to describe your work: git branch -b feature-123.
Commit to this branch only and push it to the repo. If you now create a pull request from this feature branch to the main branch, it will only contain the changes you did and nothing else.
The further pull requests highly depend on your internal workflow and branch structure. But basically this workflow applies to all new changes.
I forked a repo on GitHub, made and pushed changes to my version, and now want to send a pull request to the original repo.
How can I send a pull request with changes affecting a single file and not include the commits and changes done on the other files?
You now (January 2015) can do it directly from the GitHub web interface.
See "Quick Pull Requests":
When using your browser to edit a file on GitHub.com, the web-based commit composer lets you quickly propose a change to a new branch and then immediately open a pull request for discussion and review:
Reducing the time it takes to open a pull request lowers the contribution barrier, and having this workflow available entirely within the browser makes collaboration more approachable for people with all technical skill levels.
Create a new branch from origin/master, commit the right changes to it (you can use git cherry-pick to copy commits among branches) and create a pull request of that branch.
I've previously forked jockm/vert.x and sent him a pull request. Now I want to fork vert-x/vert.x (the upstream of jockm/vert.x) and send them a different pull request. But when I click the Fork button, unsuprisingly I end up in my tjcrowder/vert.x fork of jockm/vert.x instead. Is it possible to fork both vert-x/vert.x and jockm/vert.x simultaneously such that I can send each pull requests as appropriate?
I fear the answer may be the same as for this question about the converse situation ("there's no GitHub way, but you can add a remote repo") but I'm hoping otherwise — not least because I don't see how the answer there would allow me to send pull requests to the new remote.
There's no GitHub way (small lie, see below), but there's also nothing to fear.
By definition, your fork of a fork is a fork of the original.
When you open a pull request, you get the option to choose both the origin and the destination for your pull request. The choices available there obviously depend on the fork graph, but as long as there is a path in the graph between the 2 repositories, you should be safe.
Also, since pull requests live on the website side, you don't even need to add a remote as long as you don't want to use it from git.
Now of course, you might want to reconsider your place in that graph, and make yourself a direct child of the real upstream, but that's mostly unrelated.
As said earlier there is actually a twisted way to have multiple forks, which is to create organizations and fork in them. That way you can "own" multiple repositories in the same graph. But there's really no need to go there.
Thanks to sigma's answer, I saw that not only is the upstream repo available when I go to do a pull request on the jockm/vert.x repo, but all other forks of the upstream repo are as well. So what I ended up doing was:
Deleting my fork of jockm/vert.x and instead forking vert-x/vert.x, since mostly I want to work within the main upstream repo, not jockm's version.
Creating a branch for the commit I wanted to send to jockm, and a separate branch for the commit I wanted to send to vert-x.
Making the relevant changes to each branch.
Sending pull requests for each branch to the relevant repos, since the jockm/vert.x repo is listed as a possible target for the request (along with about 200 other forks).
I used separate branches (basically topic branches) so that those commits would remain the only thing in those pull requests, since subsequent commits on the same branch are automatically added to the pull request, and these changes needed to remain isolated until/unless merged.
It seems like the better option would be to create a branch on your fork, and create a pull request from that branch. You can use branches to "fork" your version
I didn't see any specifics on "multiple forks", so I would probably end up creating another GitHub account, under which I would do the second clone, and send the different pull request to vert.x/vert.x.
Since you can have "Multiple github accounts on the same computer" (with the right ssh config file, also described here), it is a possible workaround.
Note that, however, this is supported by GitLab, with GitLab 14.0 (June 2021):
Edit default path and project name when forking
Edit default path and project name when forking
Forking a project enables you to have an exact copy of an original repository where you can experiment, apply changes, and submit contributions to the parent project.
Your forks should have meaningful names that explain their goals, and if your project is diverging, you may need multiple forks of a single project.
In this release, GitLab now supports editing the project name and project slug directly when you create a fork.
You can now create multiple forks of the same project, each with a different name, all in the same group!
See Documentation and Issue.
You could also just create a new Organization under your profile/settings. Then you can fork different states of the same original repo through the same account.