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.
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!)
I have created a repository(of which I am the owner). My repository has about 5 contributors. We are able to review the code submitted by the contributors when they submit their pull request.
What I need to know is there a way other than me opening another account and becoming a contributor myself to get the changes I commit to the repository be reviewed by other contributors first before they are added to the repo.
Yes. If you always work in a different branch, then you can submit a pull request for merging that branch into master.
If you want all branches, and not just master, to be code reviewed, then you will need to work in a different repository. The best way to do this is usually not to open a new account that you make a contributor, but to make an organization for the main repository, transfer ownership to that, and make your main account a contributor. This is probably better for larger projects but may be overkill for smaller projects.
Either way, you can set the repository to protect the master branch and require code review for all commits by everybody (though since you’ll retain control over the repository, you can always bypass this by un-setting that first).
I want to fork a github project to fix a couple of issues and then send a pull request.
The problem I'm running into is that I've already forked the project to adapt it for another user base.
Is it possible to create a second fork? If so, how?
When I try to fork now it just takes me to the previously created fork.
There is no way to have two forks of the same GitHub project unless you use two different GitHub accounts.
So:
Create a separate GitHub account (and verify the email)
Fork the
project
Invite your main GitHub account as a "Collaborator" (from
the settings)
You may need to add the extra step of creating an organization with the new GitHub account and inviting your main github account as an owner of the organization (also make sure your new fork is in that new organization). This will let you do things like deploy automatically to a Heroku app that is connected to your main GitHub account.
Why can't we just have multiple forks???
I mean that I could just commit and push without making a pull request, but I want to do it the offical way and I want somebody else to review the changes before I push to a public project.
GitHub pull requests do not need to be submitted from a fork; they work within a single repository as well:
Pull requests are especially useful in the fork & pull model because they provide a way to notify project maintainers about changes in your fork. However, they're also useful in the shared repository model where they're used to initiate code review and general discussion about a set of changes before being merged into a mainline branch.
There's nothing stopping you from creating a pull request even if you don't technically have to. This is often considered a best practice, and GitHub's own Flow model is largely based on pull requests.
Creating a pull request within a single repository is very similar to creating one from a fork:
Create a feature branch and push your work to that branch on GitHub
In the GitHub web UI, switch to your feature branch
Click the "Compare" & review button
The trick is not to use the master branch to create pull requests. Then you won't need to create multiple forks since you can make as many branches as you need and make pull requests against each branch independently.
Given a clean forked repo, create a dedicated branch and use that branch for the pull request.
You can create branches from the web UI (although it is not obvious).
Click the branch selection dropdown, type the new branch name in the input field, and then you'll see a clickable link Create branch: <new-branch-name> as shown below. The tricky UI part is that it might not be very obvious you should click the "create branch: xyz..." — it is NOT displayed as a button or as a hyperlink, and there is NO indication that this is a clickable link. Moreover, there is NO hint whatsoever that a branch can be created until you type in the search box — anyone would probably assume that the search box is used exclusively for searching branches, and not for creating them.
In case you already made changes directly in your fork's master branch then consider moving those changes into a dedicated branch and hard resetting the master branch to the original remote so that you keep it clean for synching with the upstream repo.
See also:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository
The best way, recommended by github manual, is use command line git, mirror clone your repo and push it to your github.
https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/duplicating-a-repository
If you strongly prefer GitHub web interface to the command line, a GUI friendly workaround is create a new organization and fork to that new organization.
Another GUI way I can think of is to declare a fork as a template repo using repo's setting so you can create as many forks as you need.
I am looking to collaborate with another person, but not able to figure out how GitHub works. I have a private repository, and I have added him as a collaborator, but now what?
Does he have to create a branch to which he will work separately?
How will the merge take place?
How will the merge take place? Who can merge the code?
PS - I saw the Stack Overflow question Do collaborators have commit access on GitHub? and looked at https://github.com/account/organizations/new, so basically unless I pay $25/month, can't I have someone not see the whole Master branch code?
If you add your colleague as a collaborator to your repo (no need for organization), he will be able to push to your repo.
But he will push whatever he wants in any branch.
Unless he is pushing in his dedicated branch, that can be dangerous.
The other option is to ask him to fork your repo.
See "What is the difference between origin and upstream in github".
By using pull requests, your colleague will ask for you to merge specific commits he wants to be taken into account.
But he will have his own GitHub repo to push to, which means he can push (or break) anything he wants.
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.