Earlier quoted context omitted.
In a non-profit that I collaborate with [1] we use private repos to keep the server setup and some tickets that contain sensitive information (user data). All other code is open source. Obviously we don't want to keep api keys etc. in the public repos. [1] https://github.com/sozialhelden/wheelmap
> we use private repos ... that contain sensitive information (user data). Wait, what?
Introducing unlimited private repositories
371–380 of 662 posts
Re: Introducing unlimited private repositories
#372Earlier quoted context omitted.
I'm curious, as a solo dev, had you considered bitbicket?
I've used BitBucket as a solo dev working on personal projects, a solo consultant, and an employee on a team. It's pretty mediocre, especially if you look beyond its integration with the rest of the Atlassian ecosystem. The number of times I've wanted to search a repo for something only to have to clone it and search in my IDE is staggering.
Re: Introducing unlimited private repositories
#373Earlier quoted context omitted.
In a non-profit that I collaborate with [1] we use private repos to keep the server setup and some tickets that contain sensitive information (user data). All other code is open source. Obviously we don't want to keep api keys etc. in the public repos. [1] https://github.com/sozialhelden/wheelmap
You shouldn't be keeping api keys or other sensitive information in git at all . And please note -- if you do remove it from git, it will be available in your git history so that needs to be taken care of as well (should the repo ever become public -- a common "exploit").
Re: Introducing unlimited private repositories
#374Earlier quoted context omitted.
Even for software houses, it's VERY problematic as we add customers to projects as external collaborators and we're going to get billed for that forever, even if most customers have very light usage, and even for non active projects. I was thrilled by this news but it's going to be completely unaffordable for us. We have 29 users and 51 external collaborators. We have recently upgraded to the Platinum plan ($2460/yr)…
It feels to me like there needs to be a distinction between users and developers now they've changed their pricing model, with developers getting full git access, and users getting read-only source viewing through a browser, issues, and wikis. That way agencies can add customers for collaboration without having thousands of users to pay for.
Re: Introducing unlimited private repositories
#375Earlier quoted context omitted.
We have about 100 private repos at the moment, including internal tools, branding related components, infrastructure code and pre-release stuff that we're not developing in the open. We may just move those to AWS code commit, gitlab or gogs and switch back to a free org.
"that we're not developing in the open" Honest question... why? I totally understand the mindset of "gotta go all secret squirrel to protect our profits" but if your org isn't in it for the profits there's not much to protect? I have seen examples of people performing very naughty acts like private repos to hold plain text passwords, plain text cloud service keys, plain text corporate credit card numbers for expense…
Private repos are a good way to review code for things like plaintext passwords and service keys before it's in production. If a developer commits something with a key, and code review goes "Oh, you shouldn't have put that there," and it was public, now you have to rekey. Private repos allow that code review step to take place.
(They're also pretty useful for legacy code where eliminating all the private keys is difficult and not an immediate priority, and for the rare but existent cases where including private keys in source is the right engineering tradeoff for new development.)
There's also no way to disable pull requests and other outside comments on your code, other than making a private repo. Having it private is a simple way to avoid inviting the public to have opinions all over your repo.
Re: Introducing unlimited private repositories
#3761. Take a gazillion dollars in funding on an over-hyped valuation, 2. Go through significant organizational changes that end up with the departure of a co-founder (and more suits in the building). 3. Notice that a significant segment of your growth (VC-funded startups) are running out of money. 4. Switch to a user-based pricing to generate more revenue for investors, but spin it as a freebie "Hey! Look at the cool un…
Re: Introducing unlimited private repositories
#377Earlier quoted context omitted.
Majority user, here. I already pay GitHub monthly because I have some repos that I want private. I'm a solo dev, only hacking on side projects that may or may not be something one day, but want to keep them private anyway. My bill is about to go down, and my benefits go up. All in all, I'm quite alright with this change, agree that it's positive. I get that it gets worse if I ever take on N number of developers, but…
I'm curious, as a solo dev, had you considered bitbicket?
Re: Introducing unlimited private repositories
#378Earlier quoted context omitted.
In a non-profit that I collaborate with [1] we use private repos to keep the server setup and some tickets that contain sensitive information (user data). All other code is open source. Obviously we don't want to keep api keys etc. in the public repos. [1] https://github.com/sozialhelden/wheelmap
You shouldn't be keeping api keys or other sensitive information in git at all . And please note -- if you do remove it from git, it will be available in your git history so that needs to be taken care of as well (should the repo ever become public -- a common "exploit").
Saying that you shouldn't keep it on GitHub is different, and I might be more inclined to agree with that, but it still seems like it's not a 100% rule.
Re: Introducing unlimited private repositories
#379Earlier quoted context omitted.
You shouldn't be keeping api keys or other sensitive information in git at all . And please note -- if you do remove it from git, it will be available in your git history so that needs to be taken care of as well (should the repo ever become public -- a common "exploit").
Git is just a format for storing data with a record of how that data changed. Saying you shouldn't store it in git seems rather like saying you shouldn't store it in btrfs. It's true that if your btrfs disk image becomes public, the data is recoverable, and it's hard to reliably scrub deleted files from btrfs, but that doesn't mean it's the wrong tool for a filesystem (or a repo) that stays entirely internal. Saying…
I'd be willing to argue about that, but for my newrelic api key, a private github repo is sufficiently safe - even if I'd prefer if nobody starts having his servers report to my account.
Re: Introducing unlimited private repositories
#380I find it interesting that so many people here are unhappy with the change. Sure, prices will go up for a lot of organizations, but is $9/worker/month really a lot to pay for all the stuff GitHub offers? At Bay Area prices isn't that about 5 minutes of developer pay per month? For independent use it seems like a very positive change, in fact I'm guessing it's a direct challenge to GitLab. I was considering moving my…