I have been going through git branch and its protection rules but I am not able to identify there how to restrict specific people and give access to specific people for push on specific branches. It has options related to branch only and nothing about which user can do a push or not. Is there any way we can associate branches with specific people?
This can be done using branch restrictions when using GitHub Team, GitHub Enterprise Cloud, or GitHub Enterprise Server. There does not seem to be a way to do it with other plans.
When enabled, you can set it so that only certain users have push access to each protected branch, configured separately.
Related
we have a UI mono repo using NX workspace , we are sharing code with multiple teams.Is there a way
To allow access to Team members only the modules they own?
To create PR which can be viewed and approved by module owners (Team only)?
No, read access = entire repo. If you're using a mono repo, then read access to all or no access. See: Information about Managing Teams
Read access for PRs is same as above, but you can require certain groups of approvers for PRs that include certain paths when merging to particular branches. See Information about Code Owners and Protected Branches
No, there is no way to restrict access to only part of a repository. The Git documentation is very clear that anyone who can read or write to a repository can access all of the contents of that repository. From the gitnamespaces(7) manual page:
The fetch and push protocols are not designed to prevent one side from stealing data from the other repository that was not intended to be shared. If you have private data that you need to protect from a malicious peer, your best option is to store it in another repository. This applies to both clients and servers.
If you need granular permissions, you need multiple repositories. I generally recommend against monorepos because they usually end up growing very large and then performing poorly (well after it's too late to fix), but this is also another reason why they're a bad idea.
As for PRs which can be approved by module owners, it depends on the platform. GitHub has the CODEOWNERS file, which can be used to mandate that files owned by certain teams require a review from that team.
I'm new to GitHub and am wondering if I should create separate accounts / repositories.
I want to create an open source library. Being open source, it should allow for strangers to contribute in future (Let's ignore the fact that this is a very unlikely scenario). My worry is that creating a repository under my personal account may turn away strangers as they may feel that their contribution is not towards something personal. In addition, I want to cater to the possibility that I may no longer want to be associated with the repo anymore.
I also have a business name that I would like to use to create a private repository that will be using the above library. The repos will not even be published to github initially but if the projects fails then I will open source them to github. Basically, the name will be reserved and inactive for some time.
I know GitHub does not allow inactive accounts So, is there an alternative to needing the following:
one personal account with no repos
one organization account with one repo for that library
one organization account with no repos initially
Here are some suggestions #kylie
Option 1
Make the repo on your personal GitHub account and then private it. When you are ready to allow others to contribute to your library, just make it public visibility.
You do not need to worry about strangers looking away there have been thousands of open sourced projects that started and/or still under a personal account.
Option 2
Go ahead and make a GitHub Organization and list the projects there. Depending on your development cycle you may either place them as private or public. And may switch later.
Option 3
Make the library on your personal account once it is setup and ready for other contributors you can make a GitHub organization and transfer ownership to that organization.
Don't worry about inactive accounts or not cause I have seen accounts still public without any commits to anything that are still active for more than 4 years.
I am a student who works with github account with edu suffix. There are some repository I would like to work with my current account assigned by school. All I know is that my school account is kind of github enterprise account.Basically, I would like to always works in only one account rather than switch beteen two accounts. Is the demand weird? Cause I didn't see any similar demand before.
So what I want to know is it possible. Also I feel like misunderstanding some fundamental principle of github which I couldn't tell.
Wish some guys could point it out. Thanks.
So the problem I can read out of your question is that you want to access public repositories on GitHub. The answer to this question is you can handle this with your student account. With the Enterprise license you should even have more features like public repositories etc.
For your second part some information about GitHub which might help you to understand the first answer.
You can always access public repositories, clone them on your machine and modify them and use all the features of git locally. The only thing that is not possible is pushing to the public repository if you don't have write access to this repository.
If you want to push some modifications to this repository you can do a fork of this. Then you will have this fork under your name and you also have write access. Now you are able to push your changes to this repository.
If you want to have your modifications also in the original repository you can do a pull request with your pushed commits of your own repository. The owner of the original repository now can decide to accept the pull request. Accepting the request will merge your changes in the original repository.
I hope this was the information you were looking for.
There are two popular models of collaborative development on GitHub:
Fork & pull
Shared repository model.
How to check which model the given repository uses? How to change it?
This isn't something that's formally included a GitHub repository's settings. It's something that is determined by the repository's permissions, and it's simply a recognition of some common conventions.
Do you have push access? Then (for you) the repository is effectively "shared":
The shared repository model is more prevalent with small teams and organizations collaborating on private projects. Everyone is granted push access to a single shared repository and topic branches are used to isolate changes.
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.
If not, then it's effectively "fork & pull" (again, for you):
The fork & pull model lets anyone fork an existing repository and push changes to their personal fork without requiring access be granted to the source repository. The changes must then be pulled into the source repository by the project maintainer. This model reduces the amount of friction for new contributors and is popular with open source projects because it allows people to work independently without upfront coordination.
Note that in both cases I said "for you". It is possible and common to grant a core group of committers push access ("shared model"), while still accepting pull requests from outsiders ("fork & pull"). If this were a setting, it wouldn't be on the repository. It would be a setting for each user who may have access to the repository.
And there are many other possible models, one obvious one being a private repository where certain users may fork the repository and submit pull requests. All other users wouldn't have any access to such a repository at all.
Can someone provide me with the cheat sheet for GitHub collaboration for a team of two who want equal access/rights to the repo. I am confused as to the need to use forking which appears to make sense for a large open source project with dispersed devs but seeems like overkill when I and my partner sit 10 feet from each other.
Thanks,
Doug
If you have a small team and want everyone to have access to the repo, you can just grant them collaborator permission in the repo's admin settings. Forking isn't required if your scenario doesn't require it. (Although forking can be useful, you're also partly right: if you have a small team and know all the other team members and don't mind giving them read/write access, there's no need to fork.)
the difference between the fork and pull model and the shared repository model could be explained by the Github.com:
(https://help.github.com/articles/about-collaborative-development-models/)
About collaborative development models
The way you use pull requests depends on the type of development model you use in your project.
There are two main types of development models with which you'd use pull requests. In the fork and pull model, anyone can fork an existing repository and push changes to their personal fork without needing access to the source repository. The changes can be pulled into the source repository by the project maintainer. When you open a pull request proposing changes from your fork's branch to a branch in the source (upstream) repository, you can allow anyone with push access to the upstream repository to make changes to your pull request. This model is popular with open source projects as it reduces the amount of friction for new contributors and allows people to work independently without upfront coordination.
In the shared repository model, collaborators are granted push access to a single shared repository and topic branches are created when changes need to be made. Pull requests are useful in this model as they initiate code review and general discussion about a set of changes before the changes are merged into the main development branch. This model is more prevalent with small teams and organizations collaborating on private projects.