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.
Related
for a small startup , I employed some remote developers. However, I only want to reveal the necessary codes to a certain developer, not the entire source code.
is this kind of feature offered by GitHub? If not, please provide a workaround.
Many thanks
With git repositories in GitHub there is no way to prevent a developer from cloning the whole repository and GitHub can't filter the contents of the repository to leave out part of the data. Permissions in GitHub can only prevent access to a repository, make the whole repo read-only or grant write access to the repository.
If you really want to limit access, you'll need to split your solution into multiple pieces, each in their own git repository. You can then set permissions for each repository in GitHub.
As a developer myself I caution you against this. A developer with only part if the sources would have a hard time verifying their changes work in way you intend to and it might make it much harder for them to debug any issues that happen in development.
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 want to know whether the following thing can be achieved by Github Actions or other Github feature:
I have a repository having hundreds of file, I want to share only a few files by my developer/ team. (They can only able to saw those few files, I shared).
The program can only run successfully if a developer has all those files(hidden and unhidden both).
So, is there any way through which I can hide all my code from the team, and whenever they pull the repository, all those hidden files should be downloaded in an encrypted way, and rest unhidden files can be accessed by the developer and they can execute the whole repository successfully.
If it's not possible with Github, is there any alternative tool through which I can achieve this?
Thanks
Git does not provide access control to only parts of repositories, and it's not intended to. From gitnamespaces(7):
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.
So if you want to give a user access to only a few files, they need to live in another repository with separate access control (that is not a fork of the original). That will involve a separate history.
If the user needs the other files in order to develop the software, then you'll just have to give them access, or you'll have to provide pre-built binary assets they can download to build against.
In general, it's not practical to not trust your developers with full code access. Usually one protects this access with legal means, like non-disclosure agreements, not technical measures, since technical measures are usually easily bypassed.
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.