we had an incident one of our devs merged into master branch directly which shouldn't have happened.
We use "feature" branch that goes in "rc" branch directly - which will be QA'ed then merged into "master" after deployment.
I'd like to see if there is a way to restrict only "rc" branches can be merged into master and reject all other push.
Since we are using private repo, branch protection via github setting might not work, so I was looking into pre push hook, but will above scenario be possible?
Thank you.
looked into github setting -> branch protection : it wasn't available for private repo
looked into usage for pre push hook.. wasn't able to find good example for our usage so far.
According to the GitHub docs, you'll need at least GitHub Pro to create branch protection rules with a private repo.
There are other ways to do it, but based on how much time they'll take and what a pain they'll be to deal with, $4/month for pro is almost certainly the easiest way IMO.
Related
I am looking to create Github repos with branch protection such that any merges to main branch requires certain checks to pass. We bootstrap Github repositories using code. The issue I am facing is to enable branch protection these checks need to exist beforehand. I have tried creating a webhook on push and added code to create checks and then add rule for branch protection but this way there is a small amount of time where there is no check and anyone can merge in this time. Can someone suggest what I can do to avoid this. Thanks!
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.
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 am new to DVCS's so please bear with me...
I am the author of a software library, currently hosted as a private repository on BitBucket. I would like to release the source code of my library to the public, but with the following setup:
I would like to maintain two repositories on BitBucket, a private one and a public one.
I would like the initial contents of the public repository to be the current contents of the private repository, without any history.
I would like to continue making commmits to the private repository without touching the public repository. Then, once in a while, I would like to take a whole bunch of commits to the private repository, and push them to the public repository, as a single changeset, and with its own commit message.
How can I pull this off? If it helps, my private repo only has one branch (the main one).
Concatenating changesets
Well, concatenating changesets can be achieved with one of these technics or with rebase extension with --collapse.
Branch structure
To do what you want you must have a development branch with the detailed commits and a publish branch with the concatenated ones. As long as the publish branch doesn't have any node from the development branch as ancestor, you can push only the publish branch. That means you would have to use one of the options above, you can't merge development branch into publish branch because that would set development branch nodes as ancestors of public branch and you would have to push those nodes.
Controversy
Although this is possible, I agree with #Ringding, it shoudn't be the routine workflow. Here are two good reasons for not doing that:
You are adding unnecessary complexity to your workflow, things should be simpler.
Those development changesets are the evolutive steps that led to the final version, they are part of the history, hiding that is like lying. That's why history editing tools are extensions and not core commands, they shouldn't be part of a normal workflow.
This is easy to do. I would create a "publish" branch and merge into that whenever you want to push to the public repo. Then use the convert extension to extract only this one branch.
However, it is almost never a good idea to work like this. Potential contributors usually don't want to put up with development behind closed doors. For open source work, it's usually best to open up everything – bug tracker, source repo, wiki, mailing list, reviews, …