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.
Related
I recently started a position at a new team. Their version control and programming best practices are non-existent. I'm trying to set up some infrastructure not only for myself and the one other computational researcher on my team, but also for future potential computational scientists who may join the team in the future.
To that end, I would like to create a GitHub organization to centralize all of our version-controlled code. However, one thing that is giving me pause is the wording of the organization creation page on GitHub:
The "This Organization belongs to:" menu is a bit unclear to me.
If I specify my employer, what does that mean functionally about the use and control of the organization settings? There is no one else in my team who is interested in or even wants to be the "head" of this organization on GitHub, it's just me, but I do not want to "own" this organization; I want it to exist for others after I potentially leave. It's not mine; it's my employer's. I am creating this GitHub organization on my institute's behalf.
If I type my employer's name, is that just a legal designation or will I be abdicating power over this GitHub to an account that doesn't even exist?
There was a Github discussion about this topic.
If in the future you (Owner) leave repositories and no one takes them, the company or institution can legally initiate a formal request to Github to retrieve the repositories.
In addition, the account is under the Github Corporate Terms of Service, instead of the Standard Service terms, see:
github-terms-of-service
github-corporate-terms-of-service
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.
For example, the repo for Bitcoin Core: https://github.com/bitcoin/bitcoin
Has a contributors list: https://github.com/bitcoin/bitcoin/graphs/contributors but no special indication who has commit privileges.
There is also the "organization" list of "people": https://github.com/orgs/bitcoin/people but again no special indication or label on who has what permissions.
I've wanted the same info before and spent some time looking for an answer to this question. Unfortunately, as mentioned by myself and others in the comments, there is no really good way to do this.
By itself,git is decentralized; there is no "master server" on which users could be given a higher level of rights over the distributed code base than others. So it doesn't make sense to talk about such things in terms of pure git. But that doesn't work very well for projects in the real world, so we use things like Github to sit on top of git and act as a centralized master.
So Github bolts on top of git and adds some additional functionality, which includes some features for user management and access control. Organizations own repositories. Organizations have members and administrators. Repositories can have collaborators. And both members of the oraganization that owns the repository, and collaborators, can be granted read/write access on the repo itself.
So then your question can be rephrased as "how can I see the list of people in the organization that owns a repo, and how can I see the read/write permissions they have on that repo? And, how can I see who is added as a collaborator?"
The best answer I have been able to find is basically:
be an administrator on that organization. Navigate to the members list, click on each member, and check which rights they are granted on the repo in question. Then go to the repo itself, and under settings, click collaborators, and see who is listed there. You now have a list of people with read/write access to the repo.
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.
If my entire project is stored in a public github repo what's to stop people from downloading it and publishing it on Google play before I do?
I want to use github to keep track of changes in a group Android project, I was told an active account would also benefit future employment, and make it public to help other students. But what if I wanted to eventually publish it to Google play? See the above question.
I'm new to software development.
If you find your code online somewhere which you did not permit or without your license, you can submit a DMCA claim. Here is Google Play's takedown form and GitHub's DMCA guide.
If you want to keep your code in a private repository, try BitBucket, it's a private code repository and free up to five users.
The meaning of a public github repository is specified by github as the following:
Public Repositories can be viewed and cloned by anyone. Choose this if your repository:
is an open source project
should be easy for other members to fork and contribute back their modifications.
I would be a better option to choose private repository(paid on) to keep your code safe.
Yes, you have the option Transfer ownership so you can transfer you code to your future employer using github. Hope it helps you. Let me know if you need any further information,
Transfer this repo to another user or to an organization where you have admin rights.
If my entire project is stored in a public github repo what's to stop people from downloading it and publishing it on google play before I do?
In theory, nothing.
In practice, few people are going to run across your repository, unless you promote it (e.g., publish links to it). There are many repositories in GitHub.
Any opensource project (such as a public github repo) needs to declare a software license. In the case of github, failing to do so implies a default MIT license to any fork (clone), which gives away most rights except attribution.
GPL licenses are viral, meaning any tier in a system that contains GPL code belongs to that GPL. All published code and changes must be published back up to the original repo. This seems more suited to your repo. That would include pull requests required to license an appclone, which you could block.
Google will pull any app that clearly violates a license, and right quickly too, since they have some liability to do so. Also, developers have been known to globally broadcast their displeasure when violated.
The boilerplate license types are fairly clear and bullet-proof, as long as you don't need to change them - for that you should seek legal counsel.
Most corporations stay away from anything not clearly licensed as MIT or weaker. You can get fired for pulling GPL code into (compromising the ownership of) a proprietary codebase. GPL is for educational and partnership arrangements.
So there is obviously a clear trade-off between repo license strength and number of active contributors. An unconditional license can attract contributors, a conditional license can orphan the repo. Business is about relationships.
GitHub has created a nice website to help people decide on a license: https://choosealicense.com/
The solution is to use a private repo. You can set anyone as a contributor with write access.